Verbing Properties

• Date: Sat, 30 Mar 1996 15:08:49 PST
• From:
  Jefferson.M.Dubrule@dartmouth.edu (Jefferson M. Dubrule)
• Reply-To:
  manta@dartmouth.edu (manta)

I am currently working on a Minimal.DB MOO, and I am working on a number of
server hacks.  Here is one of them now.  When finished, these will all be
made available to the public.  I would highly appreciate any comments, flames,
compliments, money, whatever you could give me about this.

----Cut-here----- 
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. 
*  Properties need not return static values.  For
   example #0.time  could return time() 
*  Property access could be logged.
*  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.

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.
   *  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.         
*  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}).
*  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.
*  Finally, some clean-up:
   *  Properties(foo) returns the properties defined directly on foo, but not 
      in its ancestry
   *  delete_property(foo, "bar") eliminates the foo.bar, and, if foo.bar is
      -c, foo.descendents.bar.  
   *  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.
   *  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.
      *  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.

• Prev: value bytes of error codes
• Next: Re: Verbing Properties
• Index: MOO-cows
• Thread: MOO-cows