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

Re: [SERVER] triggers OR Re: wish lists

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

The question of 'if it would be as easy' is debatable.  Of course it's
doable, I'm talking an extension to the language/operation of MOO though,
not of a specific database.  A multiuser enviroment, such that MOO is,
lends itself to being able to catch events, whatever those events may be.
I think it's easier to catch exceptions thanks to the new try/except/endtry
constructs, but that is not to say that if you programmed your entire
database to catch problems/errors with !d verbs, that error catching
couldn't be done.  It's much cleaner and easier to understand when
the server takes care of it though.

<sample code talking about accessor methods removed> 

The ONLY problem if your code is that it only lets one task per object
wait for a property to change, and that assumes that accessor methods 
are actually used.  No reason why that can't change though. :)

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

Agreed.  Unfortunately, I'm used to programming in an enviroment where
there are many wizards who all program under different styles.  Of
course I can program all my code to access props via my accessor methods,
but nothing is stopping the other wizards I work with from not using
them.  This is a small point though.

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

Exactly.

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

And some huge lists and quite a bit of ticks and CPU time.  The server
would be much better at this.

> But it is fully 
> accessable from in-db now.

Most things are (amazingly enough, we have proof on E_MOO :) ).
Only draw back is the tick/seconds limits really.

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

I'm confused by your line of thinking.  I don't see how the complexity
of the server contributes to the complexity of the language.  In fact,
in my experience of trying to teach MOO, I've been asked on more than 
occasion how to wait for an event to happen, and people seem perplexed
by the fact that they have to do it themselves.
Of course, I don't mean all events; move() is obviously out, you can
catch that easy.  I think the third idea I threw out (wait(action, 
resouces)) is by far the best one, and the most flexible in terms of
the language.  But the second (wait(obj, prop)) is probally the easiest
one to use (and program into the server).

Andy.
References:
Home | Subject Index | Thread Index