# Alternate approach to Verbifying properties

David Whitten (whitten@netcom.com)
Thu, 25 Jul 1996 10:29:57 PDT

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

    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