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

# [SERVER] triggers OR Re: wish lists

- Date: Tue, 23 Jul 1996 12:37:55 PDT
- From:
- Content-Type: text/plain; charset="us-ascii"

    At 11:19 AM 7/23/96 PDT, Judy wrote:
    >   The MOO language should have the syntax of:
    >	   a += 1;
    >
    >Ew!  Please, no.  Please do not rush to turn MOO into C.
    >
    >Keep it simple.  MOO is a great first language.  Let's not complexify
    >it for little gain.

    Especially when it's questionable if this even qualifies as a gain.

    Before that, Kipp wrote:
    >The new project I'm most interested in would be flexibility enhancements.
    >Ways to create new types of variables in-db, and sorts of triggers, which
    >can change the result of a property or verb change/access.

    This would be extremely useful.  Something like read() perhaps, suspending
    the task until a condition is met.

    wait(<condition>);

    This could cause undue lag on the server though, since it would have to
    evaluate <condition> after every MOO statement, even those executed by other
    tasks.
    A much nicer syntax would be:

    wait(<object>, <property>);

    Which suspends the current task until <object>.<property> has changed.  At
    which time, the task is requeued for execution, and it can perform the
    condition itself and wait again if necessary.

    while (1)
      incoming_old = this.incoming_message;
      wait(this, "incoming_message");
      if (this.incoming_message != incoming_old)
        this:tell("[AOL guy] You have new mail!");
      endif
    endwhile

    (obviously, a bad example for message checking)
    This has greater advantage over a loop that suspends every few seconds just
    to be able to constantly check the value of a property (or that some action
    has taken place, see below), since the the task only wakes up when
    processing is necessary, it doesn't wake up to first check if processing is
    necessary.  The checking then only need to take place when properties are
    changed.  This also makes more sense since properties are one (and most
    likely the only) form of IPC that MOO has.  resume() could be made to cause
    wait()ing tasks wake up also.

    A slightly more complicated and of dubious utility idea is something like:

    wait(<action>, @<resource>)

    Where examples of <action> could be "read", "write", "chown", "chmod",
    "connect", "disconnect", etc.  I'd suggest that <action> be restricted to
    non-VR events, ie "move" would not be an ideal one (this is debateable, but
    then again, what in this post isn't? :) )
    And <resource> is dependant on what action was (excuse my matching-eval syntax).

    // a login watcher
    wait("connect", #~Munchkin)

    // in RPG settings, is the player dead?
    wait("write", "property", {#~Munchkin, "is_alive"})

    // opps, perhaps someone made $do_command() !x
    wait("chmod", "verb", {$sys, "do_command"})

    // is every object gone?
    wait("empty", "property", {this, "contents"})

    // here's a convoluted example:
    // output buffering
    while (this.notify_buffer)
      line = this.notify_buffer[1];
      if (notify(this, line, 1))
        wait("empty", "buffered_output_length", #~Munchkin);
      endif
      this.notify_buffer = this.notify_buffer[2..$];
    endwhile

    (heh, the "verb" and "property" resources would look a lot better if there
    were verbdef and propdef handles :) :) )

    I suspose this is kind of like a heartbeat task, but global in the sense
    that it's event driven and on a per object/per verb basis.

    Herf.  I'm throwing out more ideas now than I'm sure everyone wants to hear
    (or is MOO-cows becoming techy again?), or perhaps I'm just trying to spark
    discussion.

    Andy.

Follow-Ups:

- Re: [SERVER] triggers OR Re: wish lists

- From: Kristian Fuglevik <kristian@lrc.csun.edu>

- Prev: Re: [SERVER] scattering assignment (was: wishlists)
- Next: Re: [SERVER] triggers OR Re: wish lists
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index