Re: Inherited properties in MetaCard

Scott Raney ((no email))
Mon, 7 Jun 93 14:47:34 MDT

> gregc@eagle.fsl.noaa.gov (Greg Compestine) writes:
>
> > In the 1.2 and earlier releases of MetaCard, when you get a
> > display-attribute property (colors and fonts) that hasn't been set for
> > a particular object, empty is returned. When the object is actually
> > drawn, however, it uses the attributes of its parent (which in turn
> > may be inherited).
> >
> > The question: should the object return empty in these cases, or go and
> > fetch its parent's attributes?
> >
> > ("inherited" is not a good word for this behavior, as it may be
> > confused with the OO concept whereby derived objects inherit the
> > members of their base classes. It could be be argued however that
> > this earlier use is actually inaccurate since it mixes the
> > parent-child metaphor with the base-derived metaphor. Any suggestions
> > for a better term for the MetaCard behavior?)
> >
>
> If the application absolutely must know a display-attribute property
> then it will have to traverse the tree of containing objects itself. I
> think it would be better if the Metacard implemented this internally
> instead. Then only you have to get it right.

It's a one-liner for us.

> The only problem I can forsee is when there is a need to know whether
> the property has been set or is going to a default value from a
> containing parent. Perhaps the property could be available in a long
> form, with a suffix that indicates whether or not the property is
> inherited from the parent.

Please suggest a syntax for this.

How about the properties dialogs? For example, should the "Object
Colors" dialog show the parent's colors? It doesn't now, but that's
because you can tell whether an object has it's attributes set.

What about automatic reversion? That is, if an object property is set
to the same value should it revert back to "obtaining" its value from
the parent? If this isn't enabled, every time you edit any of the
properties, they all get fixed.

> One could use the words "obtain" and "provide" instead of inheritance.
> Thus the parent "provides" a default property value for its children,
> while the child "obtains" the value from the parent. Similarly, since
> Metacard doesn't implement class inheritance, I think the parent- child
> metaphor can be used without conflict. For clarity, one could talk
> about "the containing parent" and "the contained child/ren", vs. the
> "class parent" or the "subclass child/ren".

I've heard these terms used by psychologists, but not by CS types. Do
they already mean something in the CS literature?

> gerG

-- 
***********************************************************************
* Scott Raney  303-447-3936            Remember: the better you look, *
* raney@metacard.com                   the more you'll see -- Lidia   *
***********************************************************************