Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!news.maxwell.syr.edu!jfk3-feed1.news.digex.net!dca6-feed2.news.digex.net!intermedia!newsfeed1.cidera.com!Cidera!news-reader.ntrnet.net!uunet!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: [Inform] Nice simple straightforward question
Message-ID: <GIE90y.82t@world.std.com>
Date: Tue, 21 Aug 2001 01:19:45 GMT
References: <9kua39$1ei$1@news.panix.com> <9lq26q$1bi$1@cascadia.drizzle.com> <GICo2M.MG1@world.std.com> <9lrcj5$d4g$1@news.panix.com>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 61
Xref: news.duke.edu rec.arts.int-fiction:91361

Andrew Plotkin  <erkyrath@eblong.com> wrote:
>- Overriding one part of a sequence must not break another part. (If
>you put a before:Touch clause on an object, you have to call
>ObjectIsUntouchable() yourself, or that mechanism breaks. This is why
>ObjectIsUntouchable() is the wrong approach.)
[snip]
>- It must be easy to change the default sequence for *a particular
>action/object combination*. (Most objects can be examined without
>touching, but a scroll must be unrolled in your hands to be read, and
>"examine scroll" should do that implicitly.)

I'm not sure that this simple set of desires has a consistent solution.
If I understand your initial point, you want to be able to have a
before-like override that only gets called if the object is untouchable,
assuming that the verb has that constraint. (We can imagine, say,
that we have a 'before-touchable' override and an 'after-touchable'
override to allow both sorts of behaviors.)

Now, let's say, to connect to touchability, there's an examining-like
action called "MEXAMINING", where to MEXAMINE something you need to
be able to touch it.

So now we build a room with an object with a react_before-like behavior
which reacts to "MEXAMINE" on other objects with some sort of response
based around the idea that you are going to reach out and touch a MEXAMINEd
object (e.g. Bob grabbing your wrist).

Now, we support your second desire, and you build an object which, being
a rather special object, can be MEXAMINED without being touched (say,
a gravicle-emitter).

Now, how do we satisfy both the first and second constraint for Bob? Bob's
react_before-like MEXAMINE intercept naturally assumed that the object
has already been checked for touchability, because that is a precondition
on MEXAMINE. But now the gravicle-emitter disables that precondition of
MEXAMINE, and prevents it from being checked.

One option would be to only call Bob's react_before-like MEXAMINE intercept
if the object is indeed touchable; but without some explicit code on Bob's
override, we (the library) have no idea whether it assumes that the object
is touchable. In other words, Bob's code will need to explicitly declare
whether it depends upon touchability. Which is, in some ways, rather like
the current system, although arguably the current system makes the easy
cases hard and the hard cases hard, instead of making the easy cases easy.

There are three reasonable semantics for Bob's override to have with
respect to touchability and the gravicle emitter's exceptional touchability:

   Bob's override doesn't care about touchability
   Bob's override only happens if the object is touchable
   Bob's override only happens if the object is touched

The last two distinguish between two cases not yet distinguished by
the gravicle-emitters declaring it doesn't care about touchability:
is it saying "MEXAMINE of this object never involves touchability".
or is it saying "if the object is touchable, MEXAMINE behaves normally,
but if it's untouchable, go ahead and MEXAMINE it anyway" (which
would imply Bob's override still occurs if the gravicle-emitter is
touchable)?

SeanB
