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 ... -- John Austin <[EMAIL PROTECTED]>
