Hey all. Yet another in my round of badgering. Consider this code:
[code]The Learning Lab is a room.
A case is a kind of container.
A case can be openable.
A case is usually closed.
A glass box is a case in the Learning Lab.
A lead box is a case in the Learning Lab.[/code]
This compiles but does not allow a case to be opened. The command “OPEN GLASS BOX”, for example, results in “It isn’t something you can open.” So the “can be openable” was clearly not working. You also can’t do this:
A case is open.
or
A case can be open.
Same thing: both compile but cases can’t be opened. I can change line 4 above to this:
A case is openable.
That allows the opening of cases to work just fine. So clearly “can be openable” is not the same as “is openable”. That might make sense since “can be” may imply some ambiguity. But then consider the following:
A case can be open or closed.
That statement also does not work in the sense that while this compiles, this still does not allow the cases (glass box or lead box) to be opened. So again, “can be” seems to not be the way to word things. And yet … you can do something like this:
A light source is a kind of thing.
A light source can be switched on or switched off.
A flashlight is a light source in the Learning Lab.
In that case, the use of “can be” works just fine in that “TURN ON FLASHLIGHT” works.
Does the material above that does not work make sense to you? (As in: “Well, duh. Of course that doesn’t work, you utter fool!”)
What I’m doing here is looking for ways to unambiguously present the aspects of Inform that must be certain ways and cannot be other ways so that I can write documentation that accounts for people’s intuitive aspects of how to write the English-like code while guiding them towards the heuristics of Inform’s idioms.
As I understand it, “A [k] can be ” is Inform-speak for “kind [k] has the on-off property of ”. Barring other instructions, an instance of k can then be tested for -ness, which will compile but return false (since the default value of a boolean is false).
The reason why “OPEN GLASS BOX” didn’t work is because you didn’t declare it “openable”, you only declared that it could have that property. The openable property is one property, while open/closed is another:
In other words, Inform 7 doesn’t infer that just because something has the property open/closed, it must therefore have the property openable. This is because… reasons. Um. I really have no clue why, it should be doable to define “openable” as a consequence of “provides the open property,” or something.
Yes indeed. This means that now when you use a rule to test whether the umbrella is “open”, the game will not crash: it will unambiguously return a message to the effect that “no, the umbrella is not-open”. If you were then to write “The umbrella is open” in addition to “The umbrella can be open”, you’d have asserted that not only is the umbrella able to be in an open state, but it is in fact open.
I think the main confusion here might be that the case already has the openable/unopenable property, which it inherits by the virtue of being a kind of container. Therefore saying “a case can be openable” is redundant because the Standard Rules already say that “a container can be openable or unopenable”.
It might be more clear if you try it with properties that aren’t inherited from anything. Then you’d see that, for example, “a foo is blargh” behaves exactly the same as “a bar is blargh or blurgh”, and so do “a foo can be blargh” and “a bar can be blargh or blurgh” (the only difference being that in either/or properties one of them must always be set, and the default is the last one mentioned).
Okay, but that seems odd. I say that because consider this code:
[code]The Learning Lab is a room.
A case is a kind of container.
A glass box is a case in the Learning Lab.
A lead box is a case in the Learning Lab.[/code]
With this code, tying “OPEN THE GLASS BOX” – which is a case, which is a container – does not work. It says “It isn’t something you can open.” So it seems I do need the “case can be openable”, no?
No, you need “A case is usually openable” because the Standard Rules defines that containers, by default, are unopenable.
EDIT: You might be reading “case can be openable” too literally. The phrase “can be” is always only declaring that the property exists. It never sets it(*). So you shouldn’t read it as if it meant “a case can be opened”, even if it looks like that in English.
(*) except when declaring either/or properties which have to have a default value
Well, sometimes you want things to be open but not openable (which means that both the opening and closing actions can be performed on it). Say you have an archway that you want to treat as a door; it needs to be open but not openable, because you can’t close it. Or you could have a bricked-up archway, which is a door that starts closed and can be open, but isn’t openable, because the only way to make it open is to set off a bomb next to it. And then you can’t close it up again.
Jeff, I think what’s mysterious here may not be so much why saying “A case can be open” doesn’t automatically mean that you can open a case, it’s why saying “A light source can be switched on or switched off” does automatically mean that you can switch on a light source. That’s because of the details of the check rules for switching on in the Standard Rules:
Check an actor switching on (this is the can't switch on unless switchable rule):
if the noun provides the property switched on, continue the action;
if the actor is the player:
say "[regarding the noun][They] [aren't] something [we] [can] switch." (A);
stop the action.
So the rules for switching on don’t check some “switchable” property, even though that word is in the rule name; they directly check whether the object in question can be switched on.
Whereas the corresponding rule for opening:
Check an actor opening (this is the can't open unless openable rule):
if the noun provides the property openable and the noun is openable:
continue the action;
if the actor is the player:
say "[regarding the noun][They] [aren't] something [we] [can] open." (A);
stop the action.
does check a separate openable property. (Similarly for unlocking and the lockable property.) So switching on seems to be more of an exception here.
Given what I just said about why “can be open or closed” shouldn’t necessarily imply “is openable,” I guess it’s a question why we would want “can be switched on or switched off” to effectively imply “is switchable.” I suppose it’s that there are a lot more uses for open/closed things that can’t be opened or closed with a simple command. I can think of a famous puzzle involving something that’s switchable but not in an obvious way, but you can probably generally hand-code that if you need to.
PS Maybe it’d help to think of the “can be” in “A case can be openable” as “may be”; a case might be openable or it might not, but there’s no action (usually) a player can take to make it openable. What it really means is more like “some cases are openable”; but you still have to tell Inform which cases are openable.
You could also imagine a remote-controlled cage, which will be open or closed at different times, but is not openable. (Because the player cannot type “open cage” or “close cage” directly.)
Sorry for the delay in response here in terms of giving my thanks to everyone for your thoughts. I think I’m getting a better way to internalize it so I can present it as idioms.
Personally, I suspect that the reason that the standard rules treat “has an open/closed state” as a separated property from “can be opened or closed by an actor” is specifically because puzzles involving doors that can only be opened by flipping a switch located elsewhere are popular to the point of cliché in certain subgenres of IF.