One thing I'm missing here, for Finn's design below:

values[0] = null // always null.
values[1] = reference to a 'foo' Property instance
values[2] = reference to a 'baz' Property instance

Can't we just have, say, values[1] 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

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

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).


Reply via email to