…can be found here:
This all sounds very good. Thanks for posting the link.
While considering odd phraseology that you might want to deprecate and later remove, can I nominate “remove … from play”? My issue with this is that “play” is not a place or an object. “Now … is nowhere” would be more consistent with the normal I7 syntax.
–JA
I disagree – unless I’m mistaken, you can’t type “remove … from x” where x is a place or object, or anything other than “play.” So there isn’t really a false parallel with other I7 syntax – it’s a special phrasing, which is appropriate because removing from play is really a special case.
Matt
Well, it’s a one-of-a-kind syntax. That’s my issue with it. The fewer one-of-a-kind statements a language has, the better.
All you’re doing when you use “remove X from play” is removing the object from the containment hierarchy. In other words, the object still exists – you’re moving it to nowhere. So the syntax “now X is nowhere” would be more consistent.
You can currently test, “if X if nowhere”, just as you can test, “if X is in the dungeon,” so “move X to nowhere” would be parallel to “move X to the dungeon”.
Well, I just checked to see if you can test “if X is out of play” and you can’t – but it throws a helpful compiler error telling you to use “If X is off-stage” instead. But this seems like a difference of taste between a programmer (you) and a non-programmer (me); one-of-a-kind syntaxes may be bad in general, but in this case removing an item from play really is fundamentally different from moving it to nowhere in game terms, even if it isn’t in programming terms, so I think it’s OK to have a special syntax for it. And you can always say “Move X to nowhere” if you like, can’t you?
Another thing is that deprecating “Remove X from play” would require a whole lot of changes in code – over two dozen of the examples use it, and I’m sure many more games do. And I just don’t see making the syntax more uniform as a benefit that’s worth that inconvenience. (Whereas procedural rules, it seems, really do cause a lot of havoc in processing.)
No, you can’t. That doesn’t compile. This fact illustrates what I’m talking about: The syntax for doing an extremely common, useful manipulation on the object containment hierarchy is non-standard.
Also, after “remove X from play”, X isn’t actually out of play at all, because the code could later return it to the containment hierarchy, making it part of the game again. It’s only temporarily or provisionally out of play.
And thanks for the compliment, but I’m only a programmer by courtesy. I can write adequate hobbyist-level code, but I try to avoid doing anything fancy, because it makes my head hurt.
It may also be worth pointing out that in 5Z71, the error message if you try “now X is nowhere” is entirely unhelpful. One of the examples on the page to which the befuddled author is directed does indeed contain the line “remove … from play”, but this useful code is not mentioned anywhere on that page.
I have to agree with this. “Move X to nowhere” satisfies a need for formal consistency, but in terms of natural language it’s crazy robot talk that makes no sense outside the context of the formal structure of the object tree. (If someone in real life asked me to move something to nowhere, I would assume they wanted me to leave it exactly where it is.)
“Off-stage” is a much more intuitive descriptor that is more consistent with its usage in natural language, I think. You can declare that a thing is now off-stage, you can test whether a thing is off-stage, and you can use off-stage as part of a description (“the list of off-stage people” is surely better than “the list of nowhere people” and at least more succinct than “the list of people that are nowhere.”)
As far as “remove X from play” specifically goes, I don’t see how it’s a problem. The universal badness of one-of-a-kind syntax is not self-evident to me. The state of being outside the containment tree is in fact somewhat uniquely different from being anywhere else within it. Is the idea of being “out of play” misleading? No more so than being “nowhere” – one could argue that the object is not really nowhere, it is still within the collection of objects that the code can manipulate.
I wouldn’t have a problem with adding the syntax “move X to nowhere,” of course, although I don’t think I would ever use it. But I would not like to see “remove X from play” deprecated.
I believe the plan is not to revisit the deprecation issue further for the present build, but to focus on finishing the bug fixes and release. In any case, the thread here suggests that this is an issue that might bear a little more discussion.
To that end, I’ve added the suggestion to our suggestion database for the forum that is destined to go live alongside the build; perhaps that will help clarify how what preference users have about this issue.
Adding “move X to nowhere” would save a bit of confusion for some users, who would otherwise have to search for a nonstandard syntax. I see no reason to remove or deprecate “remove X from play”.
Where I’m coming from on this … I only realized it yesterday … is from T3. In T3, the syntax is this:
myObject.moveInto(nil);
This removes myObject from play, and it’s exactly the same syntax as
myObject.moveInto(upstairsHallway);
I would hazard a guess that the thinking behind “remove X from play” harks back to the repeated admonition, in the DM4, that nothing is not an object. Indeed, the DM4 is explicit that “move X to nothing” is not allowed in I6. So “remove X from play” in I7 is consistent with the earlier design of I6.
–JA
That’s what I was thinking of when I called you a “programmer” – you understand stuff that looks like this.
(Well, I might be able to pick T3 up with a fair amount of effort. But it certainly looks more programmery.)
Anyway I completely agree with this:
So, consensus?
I agree that the slew of non-standard syntax for common tasks is one of my least favorite parts about Inform 7. Embarrassingly, I didn’t even know about “remove X from play” until this very thread. I tried “move X offstage” or something similar the first few times I wanted to do so, since I remembered the syntax being something like that in Inform 6, and the compiler message was not especially useful, so since then, I’ve created a room called Nowhere or Offstage (with no map connections) and stowed things there.
The only problem with adding “move X to nowhere,” of course, is that if the author wants an actual room called Nowhere, they’re going to have to make it privately-named and such, and that seems like one of the things that new authors are less good at knowing they can do.
Well, I don’t seem to be able to make a room called “nowhere” anyway – I typed “nowhere is a room” and got “Problem. You wrote ‘Nowhere is a room’ : but ‘nowhere’ cannot be made specific, and so cannot have specific properties or be of any given kind.” – Which means adding “move X to nowhere” doesn’t even have that problem.
Could it be that you’re calling the room “offstage,” and that’s working because I7 uses “off-stage” instead?
Aha, you’re right; I was misremembering the problem I had. According to 8.10 in the Documentation, “on-stage” and “off-stage” are properties, but not ones that can be explicitly set by saying “now the X is off-stage.” Of course it is easy to see why the compiler must dismiss “now the X is onstage” as too vague (onstage where?), but I probably saw an example with “off-stage” being checked, and was confused as to how to employ it.
Anyway, yes, my Room of Undesired-Right-Now Objects is called Offstage, which works just fine because I’m not writing another Broken Legs. I thought at one point I had a Nowhere, but I’m clearly fabricating that memory. It could have been something sillier like Nohow or Noway.
I think I just had a great idea for a place to set an IF.
That design is presumably modeled on the Z-machine, where @insert_obj and @remove_obj are two separate opcodes, and @insert_obj with a destination of 0 is illegal. If the “remove” statement didn’t exist, “move” would have to be dispatched at runtime.
Actually, I’d guess that it was an attempt to keep the “is” verb from getting even more complicated than it already is. Think about the various cases:
R is a room that varies.
…now R is nowhere. [R now refers to nowhere]
R is a thing that varies.
…now R is nowhere. [the object that R refers to is now off-stage]
I think it’s a solvable problem, because “nowhere” is not actually a room reference, so the first case shouldn’t be legal. (I think.) But you can see why you might not want to tackle it.
(Supporting “X is in nowhere” would be easier, but it’s awkward phrasing – nobody would want that.)
While we’re kicking around syntaxes, I wouldn’t mind something like:
now R is a thing out of world
Cheers,
Roger
In the new release, you’ll be able to say both “now X is off-stage,” and “now X is on-stage” (which moves X to the player’s current location). So yeah, you won’t need “remove from play” any more.
Roger, are you talking about syntax for creating an object? If so, you can make something that’s not in the object tree with an assertion like “X is a thing.”
Cool.
If suggestions are still being taken, maybe allow “offstage” and “onstage” as synonyms?