John Austin wrote: > 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 tend to agree with all of this, at least in terms of which end of the spectrum we should favor. > > 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? This doesn't sound right to me. I think you may have misunderstood something, but you'll need to be more specific for me to tell. > 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. FOP's design on the SAX/DOM issue was a difficult issue for me to grasp, and when I did, I documented it here: http://xml.apache.org/fop/design/parsing.html#input There is no mismatch at all. The input we work with is a tree. Therefore a tree-like structure is absolutely necessary to represent it. I am pretty sure from past discussions with Peter that he employs a tree-like structure as part of this pull-parsing. So, if it is important for FOP to use a tree-like structure to represent its input, the only issue is whether to use DOM or some home-grown structure. Since a home-grown structure is much lighter and more flexible for our needs (AFAIK, adding business logic to a DOM would be impossible), the only question is what standard way should the home-grown structure be built. SAX provides a much lighter-weight way of building our home-grown structure than anything else that I have seen. Now, if you can figure out how to digest an FO document without building a tree that represents a page-sequence object, I hope you'll share it with the rest of us. That could be a breakthrough indeed. Victor Mote
