[ ExamineSub i;
if (location == thedark) return L__M(##Examine, 1, noun);
i = noun.description;
if (i == 0) {
if (noun has container)
if (noun has open or transparent) <<Search noun, actor>>;
else return L__M(##Search, 5, noun); ! prevents call to AfterRoutines()
if (noun has switchable) { L__M(##Examine, 3, noun); rfalse; } ! prevents call to AfterRoutines()
return L__M(##Examine, 2, noun); ! prevents call to AfterRoutines()
}
i = PrintOrRun(noun, description);
if (i == 0 && noun has switchable) L__M(##Examine, 3, noun);
AfterRoutines();
];
Since ##Examine is a “Group 2” action per DM4, would it make sense to redefine this to:
[ ExamineSub i;
if (location == thedark) return L__M(##Examine, 1, noun);
i = noun.description;
if (i == 0) {
if (noun has container) {
if (noun has open or transparent) <<Search noun, actor>>; ! here SearchSub() should handle AfterRoutines()
else L__M(##Search, 5, noun);
}
else if (noun has switchable) L__M(##Examine, 3, noun);
else L__M(##Examine, 2, noun);
}
else {
i = PrintOrRun(noun, description);
if (i == 0 && noun has switchable) L__M(##Examine, 3, noun);
}
AfterRoutines();
];
or similar? (The above was only cursorily tested.) If not, why not?
Examine, like Look, is an action where the display itself is the goal of the action, rather than a afterthought.
To borrow some terms from I7, both of these actions print their text during the Carry Out phase, not in the Report phase (as most other actions do). As such there’s usually nothing sensible to do After these actions (as that is usually intended to override the default message). That’s probably especially true if it has already printed a “nothing special about $noun” refusal.
I doubt it causes much problems in practice, as the other typical usage for After Examine would be to print some additional descriptive text following the regular description – and that wouldn’t make sense if the description itself were blank either. (You would instead move the code to the description property, in that case.)
(Also, I don’t recall whether a diverted action as in <<Search...>> implicitly returns or not – if it doesn’t, then that’s a probably undesirable change in behaviour.)
Otherwise I assume there’s probably no technical reason why it couldn’t be written that way, but it’s not completely silly as is.
The <<>> notation returns the result of the invoked action.
I’m looking not at .after() functionality but .react_after(), another important feature of Group 2 actions. At present, ##Look triggers .react_after(), while ##Examine does not (unless there is a defined description for the noun).
Starting Place
An uninteresting room.
An observer hovers nearby, watching you intently.
A rather plain throw rug is on the floor here.
The observer notes that you looked around.
>x rug
You see nothing special about the plain rug.
Here’s the demonstration code for the above:
(demonstration code)
Constant Story "Testing .react_after()";
Constant Headline "^(why are some verbs different?)^";
Include "Parser";
Include "VerbLib";
Include "Grammar";
Class Room
has light;
Room Start "Starting Place"
with description
"An uninteresting room.";
Class Person
has animate;
Person observer "reactive observer" Start
with name 'observer' 'man',
initial
"An observer hovers nearby, watching you intently.",
react_after
[;
Look:
"^The observer notes that you looked around.";
Examine:
"^The observer notes that you examined ", (the) noun, ".";
];
Object rug "plain rug" Start
with name 'plain' 'throw' 'rug',
initial
"A rather plain throw rug is on the floor here.";
[ Initialise ;
location = Start;
];
I looked at the Standard Library 6.12.4 code for LookSub(), and it never returns early prior to triggering AfterRoutines(). The explanatory note at the bottom of DM4 Table 6B implies that ##Look and ##Examine should exhibit the same behavior. So I would argue that it’s at least inconsistent at present.
Arguably, a “failure” to complete either action (e.g. in darkness) should not trigger AfterRoutines(). Does examining something uninteresting constitute failure to examine? (More deeply: Is there even a defined semantic model of action success/failure for Standard Library actions? If so, is it published? And, if not, should there be?)
EDIT: Actually, thinking in terms of action success/failure is a habit of thought from Inform 7, and may just muddy the waters for this question. The loosely analogous (but I don’t think identical) functional division in Inform 6 is between Group 2 actions (which trigger AfterRoutines()) and Group 3 actions (which do not). While I think that the idea of a defined semantics of actions is worthwhile, the plain fact of I6 is that ##Examine is defined as a Group 2 action – one that does not consistently trigger AfterRoutines().
