Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!news-hog.berkeley.edu!ucberkeley!news.maxwell.syr.edu!news.stealth.net!news-east.rr.com!news.rr.com!router1.news.adelphia.net!uunet!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: [Inform] Enterable objects
Message-ID: <GF92nA.GE6@world.std.com>
Date: Wed, 20 Jun 2001 22:33:10 GMT
References: <GF8C84.Eu4@world.std.com> <20010620114602.09193.00000162@ng-mn1.aol.com>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 53
Xref: news.duke.edu rec.arts.int-fiction:88965

OKB -- not okblacke <brenbarn@aol.comRemove> wrote:
>As long as we're on this topic, I think there are deeper problems with the
>standard library's concept of before and after.

For what it's worth, I don't believe there is a ONE TRUE PERFECT SOLUTION
to before/after. Here's a simple example that turned up when I coded the
sleeping puzzle in "Fit for a Queen":

Puzzle description:
   If player types "SLEEP" in a certain location, and a flag isn't set,
      the game prints "You're not sleepy."
   Otherwise it succeeds, and the game advances to a new location, UNLESS:
      - a particular animate is present, which prevents you from sleeping

The one true way of coding this would result in the following
sequence of events:

   Room 'before': If flag isn't set, "You're not sleepy."
   Animate1 'react_before': "The foo prevents you from sleeping."
   Animate2 'react_before': "The bar prevents you from sleeping."
   Room 'before': "Yay! You solved the puzzle."

Note that the room's before needs to run both before and after
the animate react_befores. Hence there is no one true solution,
because neither making the room before run before nor after the
react_befores would produce the right result.

In Fit for a Queen, I coded this by making SleepSub check if it
was the particular room, and running the success code in SleepSub
directly. An alternative would have been to make the room's before
test for the presence of the specific animates. I used the former
because it leaves things more OO as you add more reactors, but
neither solution is particularly satisfactory.

Another solution would be for even Group 3 verbs to run 'after'
clauses, which would give two times for the room to hook the
verb. But even if every room had two times that it ran such code,
you could imagine situations where arbitrarily interleaved logic
was desired:

   room's before
   animate1's react_before
   noun's before
   room's other before clause
   animate2's react_before
   room's third before clause

Throw an enterable into the mix and kaboom. So I'm not really
worrying about trying to find the perfect solution to all problems;
it just seems the handling of enterables is way below what you'd
like because of this.

SeanB
