> -----Original Message-----
> From: Victor Mote [mailto:[EMAIL PROTECTED]

Hi Victor,

> I know better than to take this bait, but ...

No matter... +1 for starters

>  It has already been pointed out that, if the Visitor stuff was so
> terribly complex, there were other solutions that could be applied that
> didn't sacrifice modularity.
<snip />

To be completely honest, I was a bit disappointed when after a couple of
months absence, finally able to check out the sources again, I had to find
that the whole Visitor design just got kicked out --before I even had a
chance to study it more closely... but that's personal, of course. I didn't
understand enough of it to see its particular (dis)advantages.
All I want to say: it happens often enough --and not only in
SW-development-- that ideas or proposals get turned down because those
concerned with the approval don't understand it and/or don't want to make
any effort to grasp it.
Logic a la: "Nah, looks too difficult to *me*. Let *us* not do that."

> 3. Things should be made as simple as they can be, and no simpler. More
> importantly, there are tradeoffs even within simplicity.
> Modularization is one aspect of simplicity.

I concur, and as an addition IMO, lately, it seems as if development is
focused on 'too much simplicity' --the desire to make FOP work with only a
minimum number of classes/interfaces, 'just one' class being ideal from that
viewpoint. Fact remains that with all the tasks we want FOP to perform,
source code is *never* going to be 'easy-to-follow'. It will always take
time before one is able to trace the flow of execution and actually 'see' it
at work in the source. Tibor seemed to understand it well enough, so I
decided to back his proposal...

<snip />
> So here is a promising developer that shows up with an idea.
> It helps him get his work done, and seems to make for a
> cleaner design (I haven't looked at it closely, but I haven't heard
> anybody argue with this).

Not only that. The use-case he described doesn't seem at all far-fetched.
Imagine FOP/FOray/Defoe having an AWT renderer that displays an editable
XSL-FO in one window, the rendered result in the other, and allows for
updates/modifications made in the first to be --as fast as reasonably
possible-- reflected in the rendered version, without having to render the
whole --possibly very large-- document anew every time. Those who are not at
least a little curious about this, may now leave :-)



Reply via email to