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

Patrick Lam (PLAM@musicm.mcgill.ca)
Tue, 2 Apr 1996 18:07:39 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    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