[Prev][Next][Index][Thread]

# Re: [PROG] E_PROPNF v. E_VERBNF

- Date: Mon, 30 Oct 1995 16:30:38 PST
- From:
- cc: Michael Brundage <anomaly@u.washington.edu>, joeshaw@eskimo.com, moo-cows@parc.xerox.com
- Content-Length: 2740
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- In-Reply-To: <9510301544.AA2012@localhost.crl.com>

    On Mon, 30 Oct 1995, Alex Stewart wrote:
    > Properties on descendants all have property_info's which are distinct and
    > individually settable.  I can set a child's property's info to be completely
    > different from that of the parent.  This is because properties are in effect
    > "defined" on all descendants who inherit them.  Verbs are not.  Verbs are only
    > defined on an object if they have been explicitly created for that object,
    > regardless of whether an ancestor has a verb of that name or not.  Child

    This is true according to the builtins we are currently given to access
    the verbs, and I think Michael understands this.  The question, though,
    is whether it NEEDS to be this way, or, more practically, if there is any
    benefit to be gained from modifying our ideas of either verbs or
    properties so that they are consistent.

    Michael writes:

    > > What motivated me to ask this question is the following:  Suppose you want
    > > to determine whether or not obj really defines a property named prop.  If
    > > property_info(obj, prop) = E_PROPNF, then no, and none of its ancestors does
    > > either.  Otherwise, you have to trace through its ancestors until you find
    > > one for which property_info(obj, prop) returns E_PROPNF -- the most recent
    > > ancestor which did not return this error is the one that really defines the
    > > property.
    > >
    > > But if you want to do the same thing for verbs, the value of
    > > verb_info(obj, verb) is not particularly helpful.  If it returns E_VERBNF,
    > > then that just means that that particular object does not define its own
    > > version of verb; however, an ancestor may, so that obj:verb() may still be
    > > a pefectly legitimate operation.
    >
    Alex responds:
    > I think you're assuming something which simply isn't true here, namely that
    > verb/property_info were intended for determining whether something is the
    > first to define the verb/property in question.  They never were, and the fact

    Alex goes on to allude to the fact that $object_utils:has_callable_verb
    and its ilk works around the inconsistency in verb_info/prop_info's
    reporting.  Would it be useful to have verb_info return a positive value
    even if the verb is defined on an ancestor of the obj rather than on obj
    itself, so that verb_info would then return:

    {<owner>, <perms>, <args>, <defining object>}

    Where <defining_object> is the first (or last?) verb in obj's ancestors
    to have actual verb code for the verb in question?

    Or maybe just a new builtin:  executable_info(<obj>, <verbname>)
    Which returned:

    {<owner>, <perms>, <args>, <definingobjects>}

    Where <definingobjects> lists all of the ancestors with that verb defined.

    On the other hand, I'm not sure how useful this really is. :)

    bild@io.com

References:

- Re: [PROG] E_PROPNF v. E_VERBNF

- From: Alex Stewart <riche@crl.com>

- Prev: Re: [PROG] E_PROPNF v. E_VERBNF
- Next: [SERVER]
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index