On Thu, 2003-11-27 at 13:58, Victor Mote wrote:
> Again, this is an implementation detail, and doesn't affect the interface.
> However, on the implementation side, it seems that the tradeoff will be
> between doing a full parse each time, or creating lots of objects. John
> Austin's inquiry about the huge number of objects created is what got me
> started down this line of thinking.

I am critical of what I percieve to be a pathological growth of objects
(and search times). If those problems are corrected, there are plenty of
resources left to do a few extra parses.

How often will you encounter expressions this complex ? Rarely.

If they become common (and someone will do that!), we can call THAT a
pathalogical development and <smirk>blame the victim</smirk>.

>  I suppose that the best way would be to
> have your cake and eat it too -- store integers where possible, and create
> objects where not possible, and teach everything how to tell the difference.
> (Here is a half-baked idea that I don't want to even think about pursuing
> for a while -- PropertyStrategy. With the API I have proposed, one could
> conceivably store the Properties one of several ways, and have the user
> select which one they want based on performance needs).

As Peter knows, I have been reading the code. I shall attempt the
XSL-FO Spec soon. I understand the spec defines the behavior of
the program in terms of fully parsed/expanded trees. This
implies that objects must exist even if they will never be used
after the parser moves past their end-points. Optimization anyone?

What I infer of the Tree structures in your discussion and Peter's
code suggests to me that FOP creates a DOM-ish view of the document
in one or more trees. This is a mis-match with the SAX parser that
is in there somewhere.  

And just to say something completely ludicrous, because someone
will take it seriously ...

You could convert those expressions to a Java class, compile, load
and invoke it with Reflection ... 


Reply via email to