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

# Re: [PROG] E_PROPNF v. E_VERBNF

- Date: Sat, 28 Oct 1995 14:46:50 PDT
- From:
- Cc: moo-cows@parc.xerox.com
- Content-Length: 3177
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=US-ASCII
- In-Reply-To: <199510281502.IAA19714@eskimo.com> from "Joe Shaw" at Oct 28, 95 08:02:46 am

    >The properties are actually passed down to the children. However, the
    >verbs are not... Its pointless and a waste of space. The verb is called
    >on the ancestor which has that verb.
    >[...]
    >Get it?

    Oh yes, I definitely understand the mechanics behind property and verb
    inheritance, and understand that properties and verbs are quite different
    animals.  I've been programming MOO for about eighteen months (a wee bairn
    in the eyes of some on this list, I'm sure), and am really not the total
    idiot my question may have made me appear.  Let me clarify what I meant:

    When I posted my question I was thinking that perhaps if "parent" is an
    object defining a verb and "obj" a child of parent, then verb_info(obj, verb)
    ought to default to verb_info(parent, verb), just as property_info does, or
    else property_info(obj, prop) ought to return E_PROPNF for all but the obj
    that actually defines prop.

    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.

    Conversely, if the object does define that verb, you still don't know that it
    is the first object to do so, so you may still need to trace its entire
    ancestry to find all the instances of verb on its parents (after all,
    obj:verb() might well pass() to these others).

    I'm asking if it wouldn't make more sense to treat verbs and properties
    a little more equally.  Either:

       (1) Treat verbs more like properties are currently treated.  Have an
    is_clear_verb(obj, verb) which (like is_clear_property()) returns E_INVARG
    if obj is the first obj in its ancestry to define verb, returns 0 if
    obj defines verb but has some ancestor which does also, or returns 1 if
    an ancestor defines it but obj does not.

    or (2) Treat properties more like verbs currently are.  Have
    property_info(obj, prop) raise E_PROPNF if obj.(prop) is clear,  but let
    obj.(prop) still be a valid operation if some ancestor of obj does define
    prop.

    Neither of these is intended to be a change in the way MOO inheritance works,
    but rather a way that inheritance is interpreted by the MOO programming
    language.  In practice I find it often difficult to ascertain which objects
    define what, and sometimes this leads to lost data (on inherited properties)
    or conflicting code (overriding intended inherited behavior).  It would be
    nice (IMHO) to make it easier on the programmer to discern the inheritance
    structure at a glance, without having to trace through an object's entire
    ancestry to really know what's happening.

    michael

Follow-Ups:

- Re: [PROG] E_PROPNF v. E_VERBNF

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

References:

- Re: [PROG] E_PROPNF v. E_VERBNF

- From: Joe Shaw <joeshaw@eskimo.com>

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

Home | Subject Index | Thread Index