Andreas L Delmelle writes: > OTOH, if you feel like investigating further, I personally would be > very interested to see if the properties implementation cannot be > optimized in other ways than simply removing them as members from the > FOs. > > I recently mentioned the idea of flyweights.
An excellent idea. However, before I go any further with implementing anything I'd like to make sure that I actually understand what's going on at the moment and (more importantly) what should be going on. As I understand it, objects in the fo tree describe the structure of the document and relate directly to the xsl:fo input. All these objects descend from FONode and all have a number of distinct properties which relate in some way to the input document and which may or may not have some bearing on the output (e.g. aural and accessibility properties don't have any impact whilst font and text properties do). All the property classes are supposed to be immutable even though some of them aren't and none of them use final members. Is this all correct so far? What I'm less clear on is the use of PropertyList and PropertyMaker. Some properties such as KeepProperty or EnumProperty have makers as static inner classes. Some properties such as SpaceProperty have both an inner static class and an external maker class. Some properties such as PercentLength don't seem to have any makers at all. Why? It occurs to me that the best strategy for handling these would be to turn all Makers into singletons and use use them as flyweight factories, introducing a new factory for the Common* property classes. What do you think? Richard
