MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: [PROG] E_PROPNF v. E_VERBNF

> 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.

I think you're missing the point of the differences between verb inheritance 
and property inheritance..  Let's look for a minute at the other side of 
things, set_property_info and set_verb_info..

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 
objects do not inherit verb definitions, they only inherit the ability to call
a verb.  Therefore, set_verb_info on a child will only work if that child 
defines (or redefines) the verb itself.  Likewise, verb_info only works under 
the same circumstances.

The only other reasonable alternative would be to have set_verb_info modify 
the info for the ancestor (since that's the info that verb_info would access, 
and they should be consistent).  However, having a builtin like this modify 
something which is in fact different from what it was told to modify is a bad 
idea, in my opinion.  Since children don't automatically have their own,
individually settable info for each verb on their ancestors, like they do for
properties, getting and setting such info just doesn't make sense.

> 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.

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 
that some cases of this can be determined most easily this way is only a side 
effect, not the point of the builtins.  It should also be noted that if you're
coming up with these questions because you're trying to do these types of 
tests in a LambdaCore-based system, you really should be using the routines on
$object_utils instead of rolling your own anyway..

-R
-------------------------------------------------------------------------------
     Alex Stewart - riche@crl.com - Richelieu @ Diversity University MOO
                         http://www.crl.com/~riche/
            "Difficult answers lead to intelligent questions."
Follow-Ups: References:
Home | Subject Index | Thread Index