# Frobs and other useless junk

Michael Brundage (anomaly@u.washington.edu)
Mon, 5 Aug 1996 16:01:03 PDT

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

    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