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

Re[2]: Verbing Properties (forwarded from "Seth I. Rich"<sir@po.cwru.edu

Hi Seth,

It is already possible to make data values be accessible only through
verbs, if we choose to.  However, what Jeff and I are proposing is
a mandatory verbed-properties scheme: you don't get a choice between
verb/prop (and this would eliminate $code_utils:verb_or_property or
whatever that kludge is known as)

>I'll start by noting that the described model is already workable in-DB.
>I'll illustrate by imagining that I'm adding description to the MOO.

This works for one prop.  We want it to work for all properties.

> = I add $root_class:description, as a callable verb returning "You see nothing
>   special."
> = I add a user command, @describe, which adds a :description to the specified
>   object which returns the specified text.
> = As there are no property accesses (at least none which can be assumed by
>   the model), a user who wishes to access FOO's description has no choice but
>   to call the :description verb.

This is possible, but it's not what we intend.

Under verbed_properties, every property read calls a verb that
returns a value.

Normally, as every object is a child of $root, a reference to
spoon.quack would be translated into a call to spoon:_get_quack, and
that mean a call to $root:_get_quack, which is caught by $root:_get_*.
Now, $root:_get_* cannot refer to the property by object.(name), as
that would result in an infinite recursion, so we add a server builtin
that returns the property's value itself (as far as we know, there is
no server builtin that does this- it would be redundant, after all)

Without that rationale, I will agree that set_prop_full and prop_full
do appear to be redundant.  But once prop accesses are automatically
intercepted and translated into verbcalls anyway, these server functions
become absolutely necessary.

What we are proposing is the abolition of all property accesses,
except through the server functions set_prop_full and prop_full.

This allows us to implement multiple inheritance more easily, as
we don't need to worry about properties at all: essentially, they
aren't inherited, the verbs are.

It will probably be a bit slower, but it makes the coding easier.

>Hsm.  I'll wait on this until later in the message.  In general, though, the
>single-inheritance model is really seriously built into the MOO server code
>(or so I've been told); it's probably significantly more work than you're
>expecting to do it right.

We have written drafts for implementing multiple inheritance.  This
is one of the things we need to do for it.  It is nice to get this
working properly (one of the smaller changes) before we start
serious hacking-and-burning.

I will point out, though, that 'parent' and 'sibling' are only
referred to in a handful of LambdaMOO source files.  It is pretty
well written with respect to that.

>>      *  property_full(foo, "bar"), which will return
>>         {the value of foo.bar, {OWNER, PERMS}}.
>>      *  set_property_full(foo, "bar", {quack, {OWNER, PERMS}) which will set
>>         foo.bar to quack and change the owner/perms as well.
>
>I don't like this.  It feels klunky.  These are two builtins which don't
>add real functionality.  (They both handle calls of other builtins?)

Nope.  The value cannot be set from another builtin at all, nor can
it be read.  (See above)  It is a repeat of property_info and set_p_i
though, for the info part.

Most code will not call these functions; in fact, they could be
wiz-only without dramatically affecting the code in the db.  The point
is to give $root:_set_* and $root:_get_* a way to do their job.

>>*  Second, the property modification and retrieval routines will be changed
>>   such that: (Note that perm checking is handled exclusively by the DB)
>>   *  'foo.bar' is replaced by 'foo:_get_bar()'
>>   *  'foo.bar = quack' is replaced by 'foo:_set_bar(quack)'
>>   *  property_info(foo, "bar") is replaced by
>>      foo:_getinfo_bar() (returns {OWNER, PERMS})
>>   *  set_property_info(foo, "bar", {OWNER, PERMS}) is replaced by
>>      foo:_setinfo_bar({OWNER, PERMS}).
>
>See way way above.  I'm not sure this overhead is worthwhile in-DB.

The implication here is that all property accesses pass through this,
so we don't need to fix multiple inheritance for properties, as they
will call verbs.  It does add overhead.  (the actual code would
require a for loop and a property_full() call)

>Server gurus: how much extra space is needed for a property -definition- as
>opposed to the space taken up by inheritance?

My surface reading of the code tells me that the property definition
takes up a bit of space; instead of a data type; TYPE_CLEAR is stored.
But we're not trying to save on space.

>>   *  delete_property(foo, "bar") eliminates the foo.bar, and, if foo.bar is
>>      -c, foo.descendents.bar.
>
>If properties are not inherited, why should the properties on my children be
>affected if I delete a property?

@recreate #99 as #1 named "test"
@prop #1.quack "blah" r
@set #99.quack to "bar"
@rmprop #1.quack

Obviously #99 should not keep a .quack property.

>>   *  chparent(foo, bar),
>>      *  when parent(foo) == #-1, does absolutely nothing to the properties
>>      *  when bar == #-1, delete any properties on foo which are defined
>>         directly foo's ancestors from the descendants of foo then from foo
>>         itself.
>
>If properties are not inherited, etc.?

Basically, setting an 'inherited' prop for the first time (unclearing
it) requires us to add it as a property on foo.  After all, it wasn't
created when we made it a child.

(Thus the expanded definition of properties() by the way- it needs to
filter out inherited properties)

>I'm not clear that the design here is a good one.

We think it is- although perhaps it is not 100% clearly communicated
in the draft.  I think my examples above show what we plan to do
with this though.

pat
Follow-Ups:
Home | Subject Index | Thread Index