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

# Re: Wishlist: verbs that return control to the system...

- Date: Wed, 31 Jan 1996 07:25:43 PST
- From:
- Cc: moo-cows@parc.xerox.com
- Content-Type: text/plain; charset="us-ascii"

    At 06:55 AM 1/31/96 PST, Ron Stanions wrote:
    >What I'd like to see is some way for verbs to return or maybe raise a
    > condition which would cause the command parser to continue normal
    > processing as if it had never attempted to use this verb.

    While an error code to this effect (I just use E_NACC) might be handy, I
    throught we were trying to (hopefully) steer away from server parsing.
    (advertisement: http://tecfa.unige.ch:4243/project_docs/in-db-parsing -- to
    be released soon)

    >For example:due to the order of processing if I put a 'L*ook any any any'
    > on myself it's going to override all other occurances of look.  My version
    > of look only handles look, look object, and look at object.   Problem is, if
    > I make a dresser and want to be able to 'look on dresser' or 'look in
    > dresser' I need to put those variations of the look command on the dresser.
    > However, since my

    First off, you should be using :look_self.  Second off, all that needs to be
    done is to make $room:look smarter so it will work without 'any any any',
    then define ':look on this none none' on the dresser.  In fact, the code in
    :look_self could even examine the prepstr variable to see if it was being
    examined 'on' or 'in' or 'at'.

    >look got first dibs it was given the task of processing it.  it would be
    > really nifty if I could have somewhere in my code where if (nothingdone)
    > raise E_DISCARD or something which causes the server to resume looking for
    > a 'look' on other objects.

    Server parsing is relatively simple, find the prep and objects in the
    string, search for verbs that match those, then call the verb.

    >This could be useful for many other reasons.  I could put a 'get' on the
    room that modifies the way get works, (changes dobj and iobj) then tosses
    control back to the main handlers with these new variables in place.  It
    opens up some interesting possibilities.

    Wouldn't this require a change to the scoping rules for builtin variables,
    since they would then be propagated back through verb calls?

    Something else to consider, what happens if the first call suspends(), but
    then raises E_DISCARD? yuck.

    More discussion on this topic can be found at
     http://shrike.depaul.edu/~abakun/moomail/
    I know this has been talked about before.

- Prev: Wishlist: verbs that return control to the system...
- Next: wiz override of !x ?
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index