Re: Frobs and other useless junk

• Date: Mon, 5 Aug 1996 11:40:26 PDT
• From:
  Michael Brundage <anomaly@u.washington.edu>
• Content-Type: TEXT/PLAIN; charset=US-ASCII
• In-Reply-To: <17118449@prancer.Dartmouth.EDU>

On Fri, 2 Aug 1996, Jefferson M. Dubrule wrote:
> If NO type checking were done in advance of call_verb, it would be possible to
> do something like this:
> {2,1,4,3}:sort();
> This would call $call_verb({2, 1, 4, 3}, "sort", {}), which would call
> $list_utils:sort({2, 1, 4, 3}), which returns {1,2,3,4} to $call_verb, which
> passes that back to the player.  This seems like a very cool thing to do,
> OOP-wise.

I guess I'm missing the whole point about frobs, because I don't think
they're cool at all.  Although I agree they're very OOP, I disagree that
they belong in MOO.  MOO is not all things object-oriented.  It seems to
me that adding in-db support for frobs is just going to triple the
overhead (especially if done in this way) for almost no gain, since they
can already be done in-db.  Moreover, it'll totally obfuscate MOO-code;
when I see thing:(vrb)(@args)  I expect 'thing' to be an honest-to-God
object, not just any possible MOO  value.  Who wants to debug code that
looks like

thing = $return:some_type_of_MOO_value();
return thing:add(foo);

with no clue at all to what thing is supposed to be?  I would definitely
*not* upgrade to a MOO server providing frobs support, unless I could turn
it off (permanently).

How can you do frobs in-db already?  Simple: Let's say you create an
abstract object called $value defining a generic MOO-value interface
(with verbs like add(), multiply(), and so on).  Subclass it into
separate objects (one for each type you wish to implement), even
subclassing these if you want.  Then for convenience, store these object
refs as named properties, such as $value.integer, $value.float,
$value.string, $value.array, $value.zero_indexed_array,
$value.hash_table, etc, etc. You'll also want a property which is where
the data is stored, and you may want to move generic utilities (such as
list sorting algorithms, special characters like tab, etc) onto these
objects as well (in C++ these would be static member functions and data).
Define all the operations you want on these subtypes, and instantiate
them whenever you want to use them.

For example, let's say you make a $value_factory object which has a verb
:create() for doing this work for you (plus initializing the new object).
Let's say it takes two arguments; the first describing the type of value
you wish to create, and the second containing an initial value for that
object.  This verb should raise an error if you request an unknown type
(after all, it may not be available on every MOO to which your code is
ported), so we'll catch that. Then you could do things like

try
  my_vector1 = $value_factory:create("vector", {1, 2, 3, 4});
  my_vector2 = $value_factory:create("vector", {5, 6, -1, 0});
catch (e)
  player:tell("Error creating vector: "+$value.string:print(e));
endtry
return $value.vector:convert_to_list(my_vector1:add(my_vector2));

This scheme is at least as workable as "frobs," with a comparable amount
of overhead and the bonus that you can do it *now*, without any server
hacks.  It's also totally clear what is going on, just by looking at the
code.  If you don't like the extra level of indirection, you can always
create synonyms on #0, such as $array == $value.array   Notice that you
can also create new types to your heart's content, and create types to
encapsulate all existing MOO types (and operations on them).

Of course, you can't do my_vector1+my_vector2, but (1) MOO is not C++
(thank God), and (2) you'd have a similar problem with frobs, since
$call_verb(my_vector1, "+", my_vector2) is still going to have to check
the types of my_vector1 and my_vector2.


michael

• Use for $call_verb
• From: Jefferson.M.Dubrule@dartmouth.edu (Jefferson M. Dubrule)

• Prev: Re: Fork problem?
• Next: Re: Frobs and other useless junk
• Index: MOO-cows
• Thread: MOO-cows