# Verbing Properties

"Seth I. Rich" (sir@po.cwru.edu)
Tue, 2 Apr 1996 05:58:43 PST

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

    Ok, I realize I wasn't at all helpful before, so I'll try to critique the
    proposed implementation constructively.

    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.

     = 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.
     = Useful side effects of this:
       - For values which do not change frequently for children (sensible defaults,
         for example), this represents a significant database savings as clear
         properties need not be propagated (in fact, they do not exist at all!).
       - I suspect that the verb {"return \"foo\";"} runs faster than the verb
         {"return this.(verb);"}.

    >The purpose of this draft is to propose a system for "turning properties into
    >verbs"
    >While this seems like a silly thing to do, it produces a number of benefits:
    >*  Programmers get DIRECT control over who and what accesses their properties,
    >   as such, it would not be hard to implement a $lock_utils-like system for
    >   access priviledges.

    For the case of properties which ought not be world-readable, such an approach
    already exists.  Is this added overhead quick enough to be worthwhile?

    >*  Properties need not return static values.  For
    >   example #0.time  could return time()

    I think we want to maintain a distinction between verbs and properties.  (On
    the other hand, I once coded a DB which used no properties, just for the hell
    of it.)  Stylistically, I would prefer to use a verbcall for the effect you
    give as an example.  I prefer thinking of properties as the place you store
    data, so accessing them should return the data they store.

    >*  Property access could be logged.

    Ok, true.  But for the cases in which this is desired, an approach already exists.

    >*  First step in the direction of multiple inheritance in the MOO.  With
    >   this patch in place, the properties inheritance system will be 100%
    >   dependent on the verbs inheritance system.  This will halve the problems
    >   associated with multiple inheritance.

    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.

    >How it will be done:
    >*  Inheritance will be removed, as far as properties are concerned.
    >   This is accomplished as follows:
    >   *  Two built-ins will be added:
    >      *  for BOTH of these, if bar is not DIRECTLY DEFINED (i.e. NOT
    >         inherited) on foo, E_PROPNF will be returned.  These verbs
    >         are wiz-only.
    >      *  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?)

    >   *  modifications to add_property(#1, "bar", quack, {OWNER, PERMS})
    >      *  if #1 has a child(#2) with property #2.bar already,
    >         E_INVARG is raised.
    >      *  if #1 has a blank child(#2), the property is added to #1, and #2
    >         remains UNAFFECTED.  Unlike LambdaCore, a property of TYPE_CLEAR is
    >         NOT added to #2.

    (One minor: LambdaMOO, not LambdaCore)

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

    >*  Third, four verbs will be added to root class.
    >   *  They will simulate the permissions checking and inheritance that the
    >      server used to perform.
    >   *  #1:_get_*() will call property_full, and return the value, or an error.
    >   *  #1:_set_*(quack) will call set_property_full and return quack
    >      or an error.
    >   *  #1:_getinfo_*() will use property_full to return {OWNER, PERMS}.
    >   *  #1:_setinfo_*({OWNER, PERMS}) will use set_property_full to set
    >      {OWNER, PERMS}.
    >   *  for both _set* operations, if the property exists on the parent, but not
    >      the child and the property is either +c and caller_perms() are the owner
    >      of the child, or are -c and caller_perms() are the owner of the parent's
    >      property, the property is added to the child and set appropriately.

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

    >*  Finally, some clean-up:
    >   *  Properties(foo) returns the properties defined directly on foo, but not
    >      in its ancestry

    This does not represent a change.

    >   *  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?

    >   *  clear_property(foo, "bar") will delete foo.bar, unless none of foo's
    >      ancestors define the prop, at which point E_INVARG is raised.
    >   *  is_clear_property(foo, "bar") returns FALSE if the object defines the
    >      property, or E_PROPNF if it is not in foo's ancestry.  If one of the
    >      usual errors is not generated, TRUE is returned.

    ... consistent with above specs.

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

    >      *  when neither are #-1, take the closest ancestor that is common to both
    >         foo and bar (this is the 'greatest common ancestor').  Delete all
    >         properties from the descendants of foo, then foo itself, that are
    >         defined by an ancestor, but not on the greatest common ancestor.
    >      *  In all cases when bar != #-1, a consistancy check needs to be done.
    >         *  If any property of foo is also defined on bar or any of its
    >            ancestors, return E_INVARG.
    >         *  If any property of foo's children is also defined on bar or any of
    >            its ancestors, return E_INVARG.

    If properties are not inherited, etc.?

    This reminds me of an unfinished project on LambdaMOO.  I was working on a class
    which "trusted" features to do various functions.  (There was a lot of granularity
    in the "trust" arena.)  My goal was to make a player parent which was minimal
    in functionality, but which would permit features to add "properties" (actually
    entries in a data structure which acted like properties).

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

    Seth
    ----------------------------------------------------------------------
    Seth I. Rich - sir@po.cwru.edu
                                     There is nothing more precious than
    Rabbits on walls, no problem.    a tear of true repentance.