[Prev][Next][Index][Thread]

# [SERVER] interfaces

- Date: Thu, 9 May 1996 12:17:25 PDT
- From:
- 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

Home | Subject Index | Thread Index