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

Re: New Server: Interfaces ala Java & COM

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)
Home | Subject Index | Thread Index