Closed tajmone closed 2 years ago
OK, thanks! Let's address this issue later when we know the scope of it.
OK, this Bug is not a bid deal — the reply "The OBJ doesn't belong..." is still acceptable, even though it's not the intended one (i.e. "That's not something you can put things into.") — but still, it would be good to fix it, at least for code consistency sake.
The problem with this bug is that it's tricky to handle. I vaguely remember having had a go at it, and didn't find any elegant way to tackle it down.
The easiest solution that comes to mind is to dump all the VERB
overrides on these special objects (floor
and ground
), and place an explicit check for them in each verb that might affect them, before the AND obj IN allowed OF cont
check, so that it doesn't get bypassed by it. I'm actually not quire sure how to go about this, but my guess would be to add a WHEN cont
check:
ADD TO EVERY OBJECT
VERB put_in
WHEN cont
CHECK
cont NOT IsA floor OR cont NOT IsA ground
ELSE "That's not something you can $v things into."
WHEN obj
CHECK ...
...
AND obj IN allowed OF cont
ELSE
IF obj IS NOT plural
THEN SAY check_obj_allowed_in_sg OF my_game.
ELSE SAY check_obj_allowed_in_pl OF my_game.
... or something along those lines (need to test it, it's now been a while I haven't worked with Alan code).
I can't really think of another solution since we're banging against inheritance priority here, and the fact that the first parameter obj
is processed before the 2nd one cont
in the Verbs execution — unless we can exclude the check expression AND obj IN allowed OF cont
when cont
is floor
or ground
, which I think can't be actually done (i.e. Checks can't handle chained expressions like this).
Maybe instead of changing the CHECK
clause we could intervene in the message itself:
...
AND obj IN allowed OF cont
ELSE
IF cont IsA floor OR cont IsA ground
THEN "That's not something you can $v things into."
ESLE
IF obj IS NOT plural
THEN SAY check_obj_allowed_in_sg OF my_game.
ELSE SAY check_obj_allowed_in_pl OF my_game.
I'm not sure what the ramification of these changes might be (these edge cases are entangled knots resulting from the complexity of the library elements' interconnections, so it's never easy to predict the avalanche effect that small changes might have).
Another solution could be to remove the AND obj IN allowed OF cont
condition from the VERB CHECK
, and add it at the beginning of the DOES
body — but this doesn't sound an elegant solution at all.
The problem here is that there's no way to handle this in idiomatic Alan — to overcome the conflicts between parameters processing order and verbs execution inheritance we are forced to hack our solution.
I think that one of the dumping-solutions proposed above is the best one right now.
Following what you said in #68, I've removed this Bug Issue from the v2.2
Project and milestones, and moved it into the Second Next Release` milestone.
I continue here what I was after in my other comment - sorry I am using a different thread. If we INCLUDE objects in the allowed set of the floor and the ground, we can then print a DOES ONLY at the put_in etc verbs at the floor and ground instances, having the "That's not something you can put things into." message display. It's not maybe elegant, but it is a workaround ... but let me know what you think...
And hey..., how about declaring the floor and ground supporters instead of containers?
If we
INCLUDE
objects in the allowed set of thefloor
and theground
, we can then print aDOES ONLY
at theput_in
etc verbs at thefloor
andground
instances
I find this solution a bit "entanglement risky" — hard to foresee how this might impact some end user custom definitions. Basically, we'd have to add the whole object
class to its allowed. Also, I'm not sure how this interfere with the StdLib custom way of handling allowed items via sets of objects.
how about declaring the
floor
andground
supporters instead of containers?
This seems a good approach — after all, these are supporters. Right now, I can't recall all the details of how supporters are implemented in the StdLib, and how this change of class might have a domino effect on the library (because it surely will), but I definitely think that this is a route worth exploring.
Maybe (after the v2.2
release, we should create a dedicated branch to work on this, so we cal do extensive tests to check its impact. The current test suite already covers quite thoroughly these special objects, so switching their class should produce immediate visual results in the test logs.
And hey..., how about declaring the floor and ground supporters instead of containers?
The more I think about your proposal, the more I think it's appropriate.
We might also want to ensure that ground
and floor
would have some special behavior in relation to the Hero trying to stand on them, and regarding objects being dropped, or attempts to put them on the ground/floor.
Some examples:
location
) as being lying of the floor. This would only affect dropped objects, and not objects as defined by the author (unless explicitly declared as being IN the floor/ground surfaces). There's potential in this.
Verbs like
put_in
, and other, have their ownDOES ONLY
ovverides in room objects or infloor
andground
, but some of these will never be executed due to someCHECK
s defined in the main verbs inlib_verbs.i
.Example for
put_in
:and then in
lib_locations.i
, on thefloor
instance:But the latter will never get executed, due to
CHECK
s inheritance preventing it (unless theobj
is included in theallowed
of floor, which is unlikely and unwanted).I've tested this in the Italian library and I can confirm I get the message from the
AND obj IN allowed OF cont
CHECK ("The XXX doesn't belong...") instead of the expected ("That's not something you can put things into.").Similar CHECKs in other verbs are preventing
DOES ONLY
executions in other cases too, especially with the verbs of the 'put,' 'pour' and 'empty' groups, when involving room/site objects, liquids and other specialized library classes.I'll try to add some tests to pin down all the problematic verbs and see which solution can be adopted. For now, this Issue serves as a reminder.