MOO-cows Mailing List Archive
Re: New Server: Interfaces ala Java & COM
Date: Wed, 8 May 1996 15:06:19 PDT
From: Jeff Watkins <firstname.lastname@example.org>
Content-Type: text/plain; charset=us-ascii
Organization: Primus Corp
Thanks for your incite, Michael. I hope
I can clear up what I think was just a
misunderstanding of the meaning of my
> 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
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
if ($Object_Utils:hasVerb( TheObj, "SendMessage" ))
TheObj:SendMessage( SomeMessage );
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
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:
the LambdaMOO server generates the following
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>
Subject Index |