Re: E_PROPNF, E_VERBNF

• Date: Mon, 30 Oct 1995 15:55:51 PST
• From:
  Michael Brundage <anomaly@u.washington.edu>
• Cc: moo-cows@parc.xerox.com
• Content-Length: 1323
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=US-ASCII
• In-Reply-To: <9510301544.AA2012@localhost.crl.com> from "Alex Stewart" at Oct 30, 95 07:44:46 am

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

Yes, I think you're correct on this point; I was assuming this, though
as you point out (the set_[verb|property]_info example especially clarified
this), it's really just a side effect.  So, perhaps it would be better
(from an OO point of view) to have other builtin functions to analyze object
inheritance (something like defines_verb(object, verb) -> returns the
parent of object that first defines :verb(), and similarly for props).

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

In addition to the fact that the LambdaCore doesn't do everything one
might want it to (though certainly it could do what these builtin functions
would do), there's also nothing wrong with experimentation (provided
it isn't just mindless duplication of work already done).

michael

• Re: [PROG] E_PROPNF v. E_VERBNF
• From: Alex Stewart <riche@crl.com>

• Prev: Re: downgrading to an older server? (fwd)
• Next: Editors & Robots
• Index: MOO-cows
• Thread: MOO-cows