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

[SERVER] triggers OR Re: wish lists

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