Thanks, Finn and John Austin, for your efforts here.
Victor, not to rush you, but how agreeable are you in general on switching to integer enumerations for FOP properties? (Given Alt-Design, Peter obviously approves.) I checked Alt-Design's PropNames.java[1] and liked what I saw. It doesn't necessarily have to be that particular design, just the idea of integer constants in general.
[1] http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/fo/Attic/PropNames.java?content-type=text%2Fplain&rev=1.1.2.1
Joerg? Jeremias?
In addition to the performance improvements, I suggested before we could have some form of
// very rough pseudocode checkPropertySupported (int property) { return isSupported[property]; }
to quickly index properties supported for a particular FO.
Alt.design uses BitMaps for this. Finn seems to have adopted the method. See previous references to data structures in FONode.java.
Also, for toString() implementations that will list *all* the properties for a particular FO, we might be able to have something very simple like this:
class FObj:
String toString {
String state;
for (int i; i < PROPMAX; i++) {
state += getPropertyValue(i).toString() + "\n"; }
return state;
}
It appears that using int constants gives us more ways
to efficiently work with the data.
Note that there are no compound properties in alt.design. From what I recall of the original design, properties are subclasses of datatypes which implement particular interfaces. In alt.design, property classes as such only exist as singletons, and are never otherwise instantiated. Instances of datatypes are instantiated, and associated with properties only by the presence of the property index. I suspect, without being able to demonstrate it, that the alt.design approach gives greater flexibility in assigning intermediate and undetermined values to properties.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
