Finn Bock wrote:
[Peter B. West]

Alt-design (trying the hyphen for a while) takes different approaches at different times. While building the subtree of any node, all of the properties are maintained in a HashMap, along with a BitSet of specified properties.

When the subtree construction is complete, the HashMap and BitSet are used to build the sparse array of only the relevant *resolved* property values

If I understand the Alt-design code correctly, the function calls, like from-parent(), are resolved but percentage are not resolved at this point, but still saved as an IndirectValue, right? The percentage will be resolved at a later stage?

Basically, yes. There are complications with from-parent() and from-nearest-specified-value() when used with shorthands. These have lead to the creation of the FromParent and FromNearestSpecified pseudo-types.

(not properties - one of the differences with HEAD)

I think you have mentioned this before, but is it such a big difference? HEAD wraps its datavalues in a very thin Property wrapper, but otherwise there is a one-to-one binding between a HEAD Property and its value.

I freely admit that when I started working with properties, I had only the fuzziest notion of the way they were processed in the original code. I'm not a lot better informed now. However, the idea of expressing properties in terms of data values still seems to me to be strange. Even though individual properties may *eventually* resolve to a particular basic type, the road there can be very complicated. It seemed to me that I should be able to process property values into a range of possible data types (e.g. enumerations and lengths), postponing the resolution into a particular, say, length, as long as possible.

The other issue was that some types (enumerations, strings) resolve eventually into very different types depending on the property on which they are expressed. The Rec. (and consequently the parser) allow a multiplicity of different data types in the expressions on many properties. It just seemed cleaner to me to separate properties (which have certain static characteristics) out from data types. That way, I have the option of resolving different datatypes into their final datatype downstream of the parsing and FO tree building.

I am open to enlightenment on this.

Peter B. West <>

Reply via email to