The idea of part inheritance is motivated by the concept of "parts" of a
presentation, and the way one would expect them to be inherited (e.g. if I
add or remove a button from a window, I would like a corresponding button
to be added or removed from all the instances of the window).
Examples of part attributes are parts, guides, grids, conditionals,
subtasks...
> a) Is it saying nothing more than "deep copy composite attributes" on
> inheritance?
Part inheritance means:
- For each value in the multivalued attribute, an instance (rather than a
copy) is created. So, this makes sense when the values are MM objects (or
at least this is the case for which the idea was originally concieved,
though the semantics can be extended to other non-object value types).
- (*) The propagation of values follows different (more complex) rules than
simple inheritance. For example, when values are added or removed from the
attribute in the prototype, corresponding instances are added or removed
from the attribute in the instance.
> b) Say an object O has an attribute A which is a basic type (like Boolean)
> not declare to be a "part" attribute. Do objects of which O is a
> prototype point to O's A? Or do they each have their own A?
> (I would assume the latter, in which case we can think of part as only
> having meaning with respect to composite attributes, which leads
> to the next question).
Yes, they have their own A (note that if A is a pointer, it points to the
same thing both in O and its prototypes).
I'm not sure that part inheritance should only apply to multivalued
attributes. Obviously the propagation of values as described in (*) would
not make sense for a single value, but the creation of an instance (rather
than putting a pointer) might make sense.
> c) If "part" really signifies a copying status, could we think of a more
> intuitive name than "part"?
How about "set", "components", "collection" (if we use "list" for what we
now call "collections").
Pablo