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 [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
