# New Server: Interfaces ala Java & COM

Jeff Watkins (jwatkins@primuscorp.com)
Wed, 8 May 1996 15:06:19 PDT

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

    Thanks for your incite, Michael. I hope
    I can clear up what I think was just a
    misunderstanding of the meaning of my
    previous post.

    > Other than, don't include MI?
    >
    > Inheritance in MOO is so simple that it takes only a few minutes to
    > explain it, even to someone foreign to programming.  So many people have
    > posted and said, "After learning to program MOO, learning C++ was so much
    > easier!"  However, no one has posted the converse, because C++ is a
    > horrible language with which to introduce someone to OOP.  In fact,
    > probably the only reason it's used so much in practice is because it
    > retained a lot of similarlity to C, which is so ubiquitous.

    I agree MI is quite a bit more complicated
    for programmers to understand. Myself, I get
    confused by it quite easily. For this reason
    I'm not using standard MI. I'm using snap on
    behaviors.
        A few programmers and I were discussing
    this idea and how it might be implemented in
    plain LambdaMOO based code. The biggest dif-
    ficulty I foresaw was scoping. Given the non-
    obscuring nature of MOO properties, name
    collisions are a fact of life. The name I want
    might already be used by an ancestor.

    I'm proposing to leave standard single inherit-
    ance in the server. The addition is behaviors.
    Where today in MOO code, you might write the
    following:

      if ($Object_Utils:hasVerb( TheObj, "SendMessage" ))
        TheObj:SendMessage( SomeMessage );
      endif

    Unfortunately, you have no idea whether the
    object just happens to have its own SendMessage
    method, which bears no resemblence to what you
    want to call. You could check a property, but
    we're rapidly getting into the ugly code dept.

    With the new server you could write:

      if (TheObj:implements( "Messaging" ))
        TheObj::Messaging:SendMessage( SomeMessage );

    And be assured you are talking to an object that
    understands and fully implements the Messaging
    behavior. This object might, in fact, be a robot
    or a player or any other object, but it supports
    the bahavior you need.

    The biggest problem I've ever had with MI is
    not knowing what method is actually called when
    I call an inherited method. I think behaviors,
    with REQUIRED scoping, will alleviate this
    problem and add a powerful (if not absolutely
    necessary) feature to the server.

    > One potentially useful thing MOO is missing, IMHO, is more complex data
    > types.  Hash tables, alone, would be a huge boon.  For that matter, the
    > ability to compile oft-used MOO code would also be pretty useful.  But MI?
    > no thanks.

    Well, you've touched on two other areas I'm
    addressing with the new server: complex types
    and machine code.
        Like the original SmallTalk environment,
    the new server will have two types of execut-
    able methods. The first is un-optimised byte-
    code (just like LambdaMOO). This byte-code
    flavor will always exist and will be used to
    port objects from one environment to another.
    The other flavor is hardware-dependant machine
    code generated by a local compiler. This may
    not be available on all platforms.
        With the current UNIX source, a byte-code
    method may be translated to C and compiled by
    the local C compiler to generate a shared
    object library, which is then linked into the
    server. On the Mac version, the C code must
    be manually compiled into a Code Resource be-
    fore it can be linked into the server. The
    same is true of Windows (but as I don't have
    a Windows machine, I'm not testing it right
    now).
        I'm also planning to add hashed diction-
    aries. This just seems like a great idea. I
    know I'd love to use it in some of my Moo
    code, so I'm adding it.

    There are also quite a few optimisations in
    the new server not found in the LambdaMOO
    server. Consider the following line of code:

        a= {"North","East","South","West"};

    the LambdaMOO server generates the following
    byte code:

        push "North"
        make_singleton_list
        push "East"
        append_list
        push "South"
        append_list
        push "West"
        append_list

    but because the entire list is a constant,
    the new server creates an entry in the
    constant pool with the list and only gen-
    erates the following code:

        push_const <index of list const>

    --
    Jeff Watkins
    http://www.FuturePress.com/People/jwatkins/
    mailto:jwatkins@FuturePress.com (home)
    mailto:jwatkins@primuscorp.com (work)