MOO-cows Mailing List Archive


Re: [SERVER] triggers OR Re: wish lists

On Tue, 23 Jul 1996, ThwartedEfforts wrote:

> 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>);  

Wouldn't it be as easy, with the server as it is now, to use a wrapper 
for the property change, and then start some pending task, or do whatever 
the waiting task would do in the wrapper itself?


Make !c.
Make a verb, object:set_property(<value>) which sets the value of the 
property, AND starts up the pending task.

@prop object.pending_task 0 "r"
@verb object:pending tnt "rxd"
@program object:pending
/*Whatever security checks wanted.*/
/*Whatever you want to do before waiting for a property change.*/
this.pending_task = task_id();
/*Whatever you want to do after the property has changed.*/
/*Can also use this in a while loop, if it is to be repeated for each 

@verb object:set_property tnt "rxd"
@program object:set_property
":set_property(<value>) => Sets to args[1].";
/*Whatever security checks you want on the proerty setting.*/
/*Posible sanity checks of the value.*/ = args[1];
`resume(this.pending_task/*,<posible return value from suspend>.*/) ! 

To me, this does the same thing as you want. You do need the wrapper for 
the property change, which you wouldn't need if you can ask the server to 
start a specified task when the change is done.

And making a property !c, and then makeing wrappers for setting, and 
maybe even reading, the property, is not a bad idea IMHO.

Adding the other tests mentioned, like resuming a special task when 
set_verb_info() is called on a special verb, is more of a job.
You would need wrappers for all the builtins, and lists or such, holding 
pending tasks, waiting for some special event. And testing all those 
cases, which could be done more or less inteligent, each time a builtin 
is called, would prolly take more time than wanted. But it is fully 
accessable from in-db now.

Not that I am saying everything that can be done in-db now shouldn't be 
moved to the server, just that it is a mather of need, and a hope on 
holding the complexity of the server to a low level, so MOO code still 
will be something unskilled programmers can learn and use.


Follow-Ups: References:

Home | Subject Index | Thread Index