# [SERVER] triggers OR Re: wish lists

ThwartedEfforts (abakun@forney.scinc.com)
Tue, 23 Jul 1996 21:59:06 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

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