re: property inheritence

Scott Raney ((no email))
Tue, 22 Jun 93 10:51:38 MDT

>
> From: uunet!aries.saic.com!pothiers (Steve Pothier)
>
> >> The question: should the object return empty in these cases, or go and
> >> fetch its parent's attributes?
>
> > It seems reasonable to me for empty to be returned for the API. The
> > script COULD find the inheritance source by itself, right? (using
> > SENDs)
>
> Steve, I'm not sure I follow you on this one, can you clarify? The only
> way that I can think of to find the inheritance source is to put the long
> name of the object, (which would provide group, card and stack info.),
> and then check back up the hierarchy until one of the objects returns
> a non-blank value for the property.
>
> Basically, what I had in mind.
>
> > From a scripting standpoint, I don't believe that the programmer
> > will typically be concerned with whether a property is inherited.
> > But then again, you never know. I'd suggest that, inherited or
> > otherwise, the value of properties always be returned. I'd also
> > suggest the addition of a function that returns the value of a
> > property, whether the property was inherited, and if so, the
> > object the property was inherited from.
>
> After giving the subject a bit more thought, I've come to the conclusion
> that a separate function would not be required to retrieve
> inheritance information. Use of the "long" modifier could be
> extended to provide this capability. For example, the command:
> put the textFont of field "testfield"
> might return the string "times". Using the modifier, the command:
> put the long textFont of field "testfield"
> might return the string "times inherited from card testcard".
>
> The API seems easy, I wonder if the implementation from within MC
> would be any different then the (script based) mechanism you
> described above.

Somebody talking to us? :-)

Adding a modifier to all properties would be easy since things like
the "long name" are already handled. This extension seems to solve
the problems at hand, but is "long" the right word to use?

In the case of "name" and "id" the path through the card to the stack
is given, but the "long" property is always different from the "short"
(default) version of it. In the proposed behavior, they'd be the same
if the property was inherited. How many overloadings of "long" can
*your* brain handle, or is overloading easier than sticking a new term
in there?

It seems that the consensus is that getting a property should return
the inherited property by default. How should the properties dialogs
be changed so that they indicate whether the properties are inherited?

And what about automatic reversion? If you set an object's property
to the same value as its parent, does it revert to inheriting
automatically, or do you have to set the property to empty to resume
inheriting?
Scott

> -Pothier-

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