Re: compound datatype inheritance

I rather prefer using the concept of the whole property "object"
being inherited as a unit.

Note that we in many places in the spec say that you may implement
things in any way you want (and think about them anyway you want)
as long as you achieve the same result in the end for all cases
as the spec mandates.

Anders

>Anders,
>
>Thanks for this clarification.  See below for a further question.
>
>Anders Berglund wrote:
>>>My confusion arises from uncertainty as to what the phrase "as a unit"
>>>means.  I assume that the result is 1), and that "as a unit" implies
>>>that, even though only "space-before" is defined as inheriting, the
>>>current state of the space-before "object" is what is inherited.
>>
>>
>> You are correct in saying that the space-before "object" is what is
>> inherited and thus the result is 1).
>>
>> Note that the space-before "object" has, potentially, had some
>> "value fixup" in case of inconsistent values (see the <space> datatype
>> definition in 5.11). It is for this reason that the individual
>> components are not inherited independently.
>>
>
>Given that the use of property-value functions with compounds is
>restricted, and that the inherited value is the computed value, doesn't
>this amount to the same thing as "normal" inheritance?
>
>>
>>>If that is so, is there any functional difference in treating short-form
>>>compound properties as shorthands _with inheritance capability_, and
>>>treating the specific forms of an inheritable compound as themselves
>>>inheritable?
>
>Peter

Received on Tuesday, 7 June 2005 14:41:13 UTC