One thing I'm missing here, for Finn's design below:
values = null // always null. values = reference to a 'foo' Property instance values = reference to a 'baz' Property instance
Can't we just have, say, values refer to the parent's Property instance in cases where inheritance is applicable?
I.e., for all those references to the 'foo' property instance for the children of an FO where that value would be inherited, we don't have to create a new Property instance, just a reference to the inherited instance.
Right, that is also the way I see it.
But if the problem is the *recursion* necessary to determine the property instance to inherit--here, not the memory problem, but processing speed--I'm thinking of a PropertyWindow instance as follows:
A PropertyWindow would be used temporarily during FObj
property initialization to hold references to all the
property instances that would be relevant for that
FObj should a property not be explicitly defined.
So, to populate the property instances for a particular FObj, i.e., the "values" array:
Pardon me for repeating what might be obvious, but I'll like to take a look at what information we want to store at each FObj. I can come up with 3 different strategies:
1) Only store the specified properties. That is what HEAD does now. 2) Put the relevant properties in a fast Property array and the remaining specified properties in a HashMap. For fo:root the result would be an array of size 1 for the 'media-usage' property. 3) Expect to store every valid property. For fo:root that would mean allocating an array large enough to store every defined property. This is what my patch does, and the "values" array works as the PropertyWindow.
As I understand your PropertyWindow proposal, it would allow us to implement no. 2) above. I'll try to come up with some numbers to see how much memory that would use/save compared to 1) and 3).