MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

Re: Alternate approach to Verbifying properties



At 9:29 -0800 7/25/96, David Whitten wrote:
>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:

%< SNIP %<  LONG BOTTLENECK DESCRIBED

My method would be a bottleneck only in MOOs where a wrapper to
set_property_value()/property_value() is defined (since then the server
would have to go through a in-db call change/access a property). Beside it
doesn't have to do with verbing properties (though it could be used for
that purpose).
I planned to use it as a wrappers for multiple-ownership and disk-based
properties so that it is completly transparent to the user.

Now about your method: where you trying to be funny or do you really think
it is more efficient?

You basically describe a system that would need to analyze the context in
which the property assignement/access is done, then check a list to see if
there is a verb to call to do that kind of operation or if the server
should do it, then (eventueally) try to call the verb, then when the called
verb does a property change you have to avoid rentering the verb call
loop... or can a 'property verb' call result in the call another (and
different) 'property verb' call?

Sorry, I fail to see that system as efficient.

>The advantage of special case verbs for the different operations is that
>1) its easier for new programmers to use

Wrong, having to look at 20 verbs and learn to use 20 verbs just for
property assignements will not be easier for new programmers (except if
it's a class full of K&R)

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

It increase the number if verb to maintain and debug. Updating 20 verbs
just to change the way assignement is done would be a pain. Beside until
the 20 verbs are updated you system might break. And updating 20 verbs
simultaneously is not easy.

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

Example:
{dispatchobj,"initidxrng"},  // verb called when: obj.prop[expr..expr]=expr;

Given the number of things that can happens when you play with the indexes,
I really fear you will waste a lot of your precious ticks examining the
index to figure what you should do with the value...

Yours,

Janus













References:

Home | Subject Index | Thread Index