[SERVER] interfaces

• Date: Thu, 9 May 1996 12:17:25 PDT
• From:
  ThwartedEfforts <abakun@scinc.com>
• Cc: new-moo@futurepress.com
• Content-Type: text/plain; charset="us-ascii"

>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.

This could be done really easily without having to add/change the syntax of
verb calling, assuming you are smart from the start when designing a core
database and keep this in mind.  This hints back slightly on Rog's name
spaces idea.

If I want to define a new interface, say the 'mail' interface, then I prefix
all the verbs that have to do with the mail interface with 'mail_', and add
a :mail_* verb to handle trying to pass messages to
unimplemented/unused/unprogrammed methods.. er, better explained with code
samples, me thinks.

@verb $root_class:implements_interface
@program $root_class:implements_interface
if ($interfaces:check_interface(args[1], this))
  or something like that, possiblity defering the check somewhere else...
  but otherwise checking to make sure that it defines all the verbs that
  the passed interface requires... for the following example, that would be
  :mail_*, :mail_receive_message, and :mail_list_messages.
  return 1;
endif

@verb $player:mail_receive_message
@verb $player:mail_list_messages
@verb $player:mail_*
@program $player:mail_
raise(some special error code signaling 'Unimplemented message');

And since $mail_recipient also defines these methods, in the same interface
'name space', then both mail recipients and players can receive mail, and
the interface is publicly known.

Now, perhaps we want to make a container that is able to receive mail.  We
just define and program the same interface (in this example,
:mail_receive_message and :mail_list_messages and :mail_*) on that
container, and it's now able to handle mail requests and receive messages
sent via the mail interface.

And you can thusly check to if an object implements a certain interface with:

object:implements_interface("mail")

returning truth, so you won't necessarily need to catch the raised error.

I'm sure I'm not telling anyone anything new.  (people seem, recently, to
want to talk about what object defines the builtin functions and how to set
up $network, so who knows what people what to hear -- the MOO-Cows mailing
list archive: http://tecfa.unige.ch:4243/moomail/)

This also has the advantage, slightly, of keeping the same number of string
comparsions as there currently are (You mention the increased number of
string comparisions as being a drawback on the NewMOO web page).

This fixes a bunch of name space problems, for example, I have three objects:
  $player
  $mail_receiving_object
  $page_receiving_object

Now, I want to make an object that is all three (or leasts is one, and
defines the interfaces of the other two).  Unfortunately, both
$page_receiving_object and $mail_receiving_object both define a
:receive_message verb, and this is where the conflict is.  I can't define
the complete $mail_receiving_object interface on the new object along with
the same interface for $page_receiving_object.
If all the methods having to do with the $page_receiving_object interface
started with page_ and those concerning the $mail_receiving_object interface
started with mail_, then it's easy to see which verbs concern what
interface.  And you can also keep track of which objects define which
interfaces easier this way.

In otherwords, I think it's going to be much easier to start from scratch
instead of trying to retrofit the current paradigm into an interfaces
implementation.

People need to actually communicate what they are doing, ie that the 'mail
interface' name space and all verbs starting with mail_ are for receiving
mail. Then again, name space name collisions seem to be something the people
haven't really considered.  
Communication is the key in multiuser development enviroments.  That and
competent programmers.

Andy.

• Prev: Re: [server&db] suggestion for .program..
• Next: ANSI+
• Index: MOO-cows
• Thread: MOO-cows