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

Alternate approach to Verbifying properties

Someone (on moo-cows) suggested: 
>If there are to be synyax changed, I would rather like see obj.foo = bar;
>to implicitely call set_property_value(obj, "foo", bar), so a wrappers
>assignement on property assignement. (and of course bar = obj.foo; would do
>an implicit call to property_value(obj, "foo")...
 
In my opinion, having this exact way would be a bottleneck on the server.
I would support the idea of having a call like:
 
define_property_verbs(obj,"prop",verblist);
where verblist is:
{
  {dispatchobj,"typeofverb"},  // verb called when: typeof(obj.prop)
  {dispatchobj,"tostrverb"},   // verb called when: tostr(obj.prop)
  {dispatchobj,"toobjverb"},   // verb called when: toobj(obj.prop)
  {dispatchobj,"tonumverb"},   // verb called when: tonum(obj.prop)
  {dispatchobj,"tointverb"},   // verb called when: toint(obj.prop)
  {dispatchobj,"tofloatvb"},   // verb called when: tofloat(obj.prop)
  {dispatchobj,"clearprop"},   // verb called when: clear_property(obj,"prop")
  {dispatchobj,"recyclevb"},   // verb called when: object is recycled
  {dispatchobj,"initialise"},  // verb called when: obj.prop = expr;
  {dispatchobj,"initindex"},   // verb called when: obj.prop[expr] = expr;
  {dispatchobj,"initidxrng"},  // verb called when: obj.prop[expr..expr]=expr;
  {dispatchobj,"updateverb"},  // verb called when: obj.prop = expr;
  {dispatchobj,"updateindex"}, // verb called when: obj.prop[expr] = expr;
  {dispatchobj,"updatidxrng"}, // verb called when: obj.prop[expr..expr]=expr;
  {dispatchobj,"retrieveverb"},// verb called when: var= obj.prop;
  {dispatchobj,"indexverb"},   // verb called when: obj.prop[expr]
  {dispatchobj,"idxrangeverb"},// verb called when: obj.prop[expr..expr]
  {dispatchobj,"spliceverb"}   // verb called when: @obj.prop;
  {dispatchobj,"spliceindex"}, // verb called when: @obj.prop[expr]
  {dispatchobj,"spliceidxrng"},// verb called when: @obj.prop[expr..expr]
})
 
I make the distinction of initializing a property and updating a property
because there are different concerns when you are putting the first
value into a property and when you are changing an existing value.
Especially in regard to maintaining constraints on values. 

Upon initial reading this may appear to be overkill, but this method has
several advantages.  In fact, I can see the utility in separating
the references where the prop value is stored into another variable and
those where you are storing into another property and finally those where
you are just using the value in some comparison or expression.
If you know it is going to be permanently stored in a property, you may
be able to handle efficiently some things that you wouldn't be able to
depend on if you are storing in a local variable or using in an expression.
If you know its only going to be used in an expression, you know the value 
won't be around very long so you may be able to get away with cutting some
corners as well.
 
I also wonder if handling the cases of obj.prop[$] and obj.prop[expr..$]
should also be special cased. Since the server knows some idioms like 
obj.prop = {@obj.prop, expr} perhaps they should be special cased.
I'm inclined to think this might be a good idea as well.  

I think the verbs called by tostr(), tonum(), toobj(), tofloat(), and 
toint() should be required to return a value of the appropriate type
or raise an error.  But this should generally be true.  Each of these 
verbs called should each have well defined numbers of arguments and
expected return values or return types.
  
Of course, if a verb is defined for obj1.prop and obj2 is a descendant
of obj1, the verb on obj1 should be called when obj2.prop is used.
 
The advantage of special case verbs for the different operations is that
1) its easier for new programmers to use
2) the context that the verb is called from is more limited,
   thus it is easier to figure out what you want to do.
3) this method lessens the impact of one verb that works improperly.
4) since there will be a time penalty when calling MOO-code from within
   the server, it is important that the verbs be able to do exactly
   one thing, and not spend a lot of time determining anything but what
   they are expected to do. This will lessen the chances of run-out-of ticks
   or run-out-of seconds errors.

Rocky @ ParkMOO(sun1.newport.ac.uk:7777), Boriz @lotsaMOOs.
David Whitten  (713) 791-1414 ext 6116
Follow-Ups:
Home | Subject Index | Thread Index