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

Re: Frobs and other useless junk

On Mon, 5 Aug 1996, Andrew Bakun wrote:
> The problem with this is that in an OO language, ALL of the basic types
> should have object equlivents, that way, when you do call thing:verb(@args),
> if thing is not an object, it gets promoted to one, and then the call is made.

To me, basic data types are basic in the sense that their behaviors are
fixed and unalterable (though one should be able to somehow subclass them
and then modify the behavior of their children).  Basic data types are
the building blocks with which we describe more complicated operations.

I suppose we could be truly reductionist, define a single basic data type
"bytestream," and let every other data type involve some sort of
interpretation of a bytestream (self-identifying objects).  Then things
like strings and floats could have all their intrinsic properties
determined in-db (by working directly with the bytestream).  Java does
this, and maybe MOO should too.

Instead, we have several immutable "basic" data types that we all know and
love (or hate). :)  This approach is both less flexible and more
intuitive.  I agree that it could be nice if {2, 1, 4, 3}:sort() [the
example to which I first replied] first instantiated a list object, then
initialized it with {2, 1, 4, 3}, and then called its :sort method.  As I
pointed out, this can already be accomplished in-db with

($some_utility_object:instantiate_a_list_object({2, 1, 4, 3})):sort();

and that if one wants to be a little more fancy (and general) one can make
a factory to do the instantiations in a uniform and friendly manner.

Alternatively, the MOO server could toss all its basic data types, and use
objects instead, handling all these in-between steps for us. In other words,
objects would be the only basic data type -- things like #43, {2, 1, 4,
3}, "hello" are all just shorthand notations for objects (either
temporary or persistant).

By either wrapping the basic data types with objects (in-db), or by
replacing them with objects altogether (in-server), one can accomplish all
these things being described. If {2, 1, 4, 3}:sort() is really and truly
treated as a verb call on an object (representing the list {2, 1, 4, 3}),
great.  However, I definitely  do not want to see {2, 1, 4, 3}:sort() when
{2, 1, 4, 3} is still considered a "basic" data type (list), because then
it's just a mangling of syntax, with absolutely no gain.  If it's
eventually going to be translated into $list_utils:sort({2, 1, 4, 3}),
then should do that right from the start.

> >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
>
> It's going through a third party to create them.  Not that this is all bad,
> since you have to call a method on the object to get an instance of it.
> Assuming we had a vector type on E_MOO, we'd use $type.vector:new() to get a
> vector instance.

Sure, fine; you could similarly wrap that in a try statement to catch
E_PROPNF in case there is no $type.vector

> Your code example is a little confusing also.  I can't figure out why you'd
> have $value.string define a :print method that would handle any type.  I
> think it would make more sense to define a frob/datatype to handle values of
> the same type that e is, and do
 [e:tostr()]

Well, you know, I was about to type $string_utils:print() [old habits die
hard].  You also say that "this is where frob support comes in handy."
Why?  My understanding (probably flawed, since as I originally posted, I
don't see why frobs are so cool) is that frobs were originally intended as
cheap, "lightweight" objects, for use in temporary situations (such as {2,
1, 4, 3}:sort()) -- instead of creating a new object encapsulating
that data type and then throwing it away not two steps later, the
MOO-server helps you (and itself) out by doing the instantiation for you,
but with something less than a full-blown object (so there would be a
smaller creation penalty).  In other words, frobs would essentially
bootstrap the basic data types into (almost) object status, but without
slowing the MOO server down to a crawl as someone does a

while(length(mylist)<10000)
	mylist = {@mylist, (mylist:length()):tostr() };
endwhile

However, then we still can't subclass the basic data types or alter how
they interact, right?  So all we've gained is the ability to put a basic
data type on the left side of a colon.

[digression]
> >return $value.vector:convert_to_list(my_vector1:add(my_vector2));
>
> Mmh.. what does $value_factory:create return?  An object?  It would have to
> in order for the above line to work.

I would want it to return an object, yes.  I want only objects on the left
side of colons.  Objects I can mutate, objects I can subclass, objects I
can alter in every way imaginable.  But like I've been saying, others
are proposing that lists and things be on the left.  Yuck.
[end digression]

> >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.
>
> Comparable amount of overhead?  Assuming your example above actually would
> work with no server mods, there would actually be a large amount of overhead
> in the constant object creation, destruction, and garbage collection that
> needs to go on.  If frobs were in server, then garbage collection is no more
> overhead than for other MOO values.

My example works now, definitely with no server mods.  That was the whole
point.  Frobs seem to gain on server overhead -- but using basic data
types is a bigger gain still!  So why bother with frobs at all (since you
can't alter their behavior or subclass them or do anything objects ought
to be able to do or have done to them)??

> The degree of clearness completely depends on the code being used, not the
> semantics of the language and it's type support.

It depends on both; clarity is definitely partly intrinsic to a language.

> Its debatable if C++ is a good example of OO.

I definitely didn't mean to imply this.


michael
References:
Home | Subject Index | Thread Index