Re: Crossposts

["Peter B. West" <pb...@powerup.com.au>]

Dear list,

This is a response to some suggestions from Arved, excerpted below. 
Please excuse the cross-posting, but the explanation should go to both 
ends of the posts.

I find myself, willy-nilly, in the process of re-designing and, 
piecemeal, rewriting chunks of FOP.  I'm doing it because I can't read 
the existing code, because I need a clean and flexible design base to 
work from, and because I want to.  At the moment I'm pretty much on my 
own, but that may change.  If not, too bad.  That's the beauty of open 
source.  It's not Software Corp.

My code blindness may simply reflect my not yet having an adequate grasp 
of this OO stuff, but I don't think that is the whole story.  If the 
current design were good (and beautiful and true), rather than merely 
adequate, then surely the sensible thing would be to map the lot into 
C++ and C where necessary.  That's not what is going to happen.  In 
fact, a more likely scenario is that the C design, if it proves 
successful, will be retro-fitted into Java.

When I have cross-posted, it has been for very specific reasons; either 
because it was a design issue which is of common interest to both the 
direction I am taking, and to any design discussion for the problem 
domain, or because specific things that I am doing map trivially into a 
C/C++ solution.  All that I have posted concerning FObjects.java and 
FOPropertyConsts.java falls into this latter category.  These classes 
represent a great deal of donkey work in providing useful expressions of 
the sets of constants which I imagine are absolutely essential to C, at 
any rate.  A few vi or emacs regular expressions will convert them into 
pure C, and save someone days of effort.

As for switching my efforts entirely into xslfo-proc: I would have to 
learn C++, which I am loathe to do.  FOP is my Java training ground, and 
Java will hopefully allow me to remain in a unix/linux ghetto, forever 
shunning NT and all its spawn.  I'm a terrible bigot when it comes to 
Microsoft.

So I will continue with my attempts to wrestle, for my own satisfaction, 
some comprehensive and comprehensible design from the spec.  Successful 
or no, I can't see that process being irrelevant to xslfo-proc.  And 
along the way there may be some more bits of multi-cultural code.

Thanks for the feedback, Arved.  What's your work situation like in - 
where are you? - Nova Scotia?

Peter

Arved Sandstrom wrote:

> Hi, Peter
> 
> I am not dumping cold water on your enthusiasm, but I wish to point out that 
> some of your posts have little relevance to xslfo-proc, which is C++ (with C 
> libraries), and will probably be architecturally considerably different from 
> FOP.


....

 
> As I say, I wouldn't mind seeing you help out with xslfo-proc. But it would 
> reduce confusion if the posts to that list were not crossposted to FOP.


....


> I suggest that you introduce yourself on the xslfo-proc list, explain what 
> you were about and are about, and indicate that you intend to assist with 
> high-level design, if that strikes your fancy.
> 
> Regards,
> Arved
> 


-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [Xslfo-proc-devel] Re: Crossposts

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

At 12:37 AM 11/2/01 +1000, Peter B. West wrote:
>This is a response to some suggestions from Arved, excerpted below. 
>Please excuse the cross-posting, but the explanation should go to both 
>ends of the posts.

Similarly, please excuse the temporary crosspost.

>I find myself, willy-nilly, in the process of re-designing and, 
>piecemeal, rewriting chunks of FOP.  I'm doing it because I can't read 
>the existing code, because I need a clean and flexible design base to 
>work from, and because I want to.  At the moment I'm pretty much on my 
>own, but that may change.  If not, too bad.  That's the beauty of open 
>source.  It's not Software Corp.
>
>My code blindness may simply reflect my not yet having an adequate grasp 
>of this OO stuff, but I don't think that is the whole story.  If the 
>current design were good (and beautiful and true), rather than merely 
>adequate, then surely the sensible thing would be to map the lot into 
>C++ and C where necessary.  That's not what is going to happen.  In 
>fact, a more likely scenario is that the C design, if it proves 
>successful, will be retro-fitted into Java.

What is currently happening with FOP is a pragmatic rewrite of just those 
things that absolutely have to be changed, spearheaded by Keiron Liddle 
(with support and encouragement...). The point is, the original FOP design 
was exceeded a year ago, give or take - many things were not accounted for, 
and they are not easily added. Hopefully xslfo-proc will do things right 
from scratch (one possible right way, mind you, not the only one). Maybe 
decisions made, and experience gained, during this process will inform a FOP 
2 design.

>When I have cross-posted, it has been for very specific reasons; either 
>because it was a design issue which is of common interest to both the 
>direction I am taking, and to any design discussion for the problem 
>domain, or because specific things that I am doing map trivially into a 
>C/C++ solution.  All that I have posted concerning FObjects.java and 
>FOPropertyConsts.java falls into this latter category.  These classes 
>represent a great deal of donkey work in providing useful expressions of 
>the sets of constants which I imagine are absolutely essential to C, at 
>any rate.  A few vi or emacs regular expressions will convert them into 
>pure C, and save someone days of effort.

I agree. I think that this helps clarify what you are about. I tend to agree 
that there is a fair amount to be learned from how FOP does things, whether 
good or bad.

>As for switching my efforts entirely into xslfo-proc: I would have to 
>learn C++, which I am loathe to do.  FOP is my Java training ground, and 
>Java will hopefully allow me to remain in a unix/linux ghetto, forever 
>shunning NT and all its spawn.  I'm a terrible bigot when it comes to 
>Microsoft.
>
>So I will continue with my attempts to wrestle, for my own satisfaction, 
>some comprehensive and comprehensible design from the spec.  Successful 
>or no, I can't see that process being irrelevant to xslfo-proc.  And 
>along the way there may be some more bits of multi-cultural code.

I don't think it is irrelevant either. You are operating at the high-level 
design level, where Java or C or C++ is not really an issue. I think the 
extra input into design is valuable, certainly from the xslfo-proc 
perspective. I should ask, are you using a UML tool, and if so, which one? 
If not, it would be nice to get some of your ideas translated into formal 
concepts. Good thoughts seem to wither away and be ignored if they stay
in email.

>Thanks for the feedback, Arved.  What's your work situation like in - 
>where are you? - Nova Scotia?

Thank you for asking. :-) The company I worked for ceased operations last 
week. It disappeared. It closed down. It went away. It shuffled off this 
mortal coil. &c. &c.

So I am starting up an interesting contract that will occupy me for a month 
or two, something that fortunately does not involve wireless or J2EE at all, 
and plan to conduct a job search at the same time. But not here...Nova 
Scotia IT has been hammered pretty badly.

Regards,
AHS



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org