It is at this point of the manual that I usually gloss over because I am confused by this concept. But this is all about really reading and understanding everything in the manual, so I am going to dig deeper this time. Fair warning, it’s pretty detailed and probably of absolutely no use to anyone but I did make myself a promise that I would really understand this stuff this time around.
I understand kinds of values or named values or enumerated values, because it is a common programming idea. But when we start talking about assigning properties to enumerated values, the lines between “object” and “value” start to blur for me. As Inform 7 for Programmers puts it:
Named values can be used almost anywhere an object can. Plus there’s a few phrases with named values can used but objects can’t, since multiple object instances don’t have any sort of ordering to them.
Side Note: Yes, enumerated values have order, if you need it, but I like them even more because they allow me to assign human-readable names to much less human-readable numbers that the computer understands. In fact, without actually understanding how they work under the hood, I think of them as arrays with nice constant names, so I can write something similar to rainbow_colors[ORANGE]
instead of rainbow_colors[2]
, where I don’t have to remember if I started my ROY G BIV ordering at zero or at one. I just know the relative ordering.
The phrase that really interests me here, though, is “Named values can be used almost anywhere an object can.”. So, if values can have properties and can be used in many places that objects can be used, besides the ordering, how are they different from objects? And where do they “live” in the game?
Objects live in the object tree. I know because I can see them when I compile the follow code:
Lab is a room.
Brightness is a kind of value.
The brightnesses are guttering, weak, radiant and blazing.
A lantern is in the lab.
The lantern has a brightness.
The lantern is blazing.
And then I type tree
:
>tree
(Compass object) (546490)
the north
the northeast
the northwest
the south
the southeast
the southwest
the east
the west
the up
the down
the inside
the outside
(thedark object) (546522)
(VPH_25) (546554)
(VPH_2) (546586)
Lab (547034)
yourself
a lantern
There’s my compass object (it’s a pretty long print out so I won’t include it in subsequent examples), the dark room object, a couple of internal objects I’m not going to worry about right now (although if someone knows what they are I would appreciate a reply just for my own info), the Lab, my PC and the lantern.
Some of these objects have names that the player can refer to in the command parser, like yourself (i.e. x me
) and the lantern (i.e. x lantern
) and even the compass directions (i.e. x north
). But not the (Compass Object) or (thedark object) or the VPH objects. Those are internal objects the player never directly interacts with.
I don’t see my brightness enumerated value there, nor would I expect to. It hasn’t been instantiated, it’s not an object in the game world and I don’t expect the player to be able to refer to brightness from the command line. But I can see it in the Kinds index:
Now let’s add a few lines of code:
Lab is a room.
Brightness is a kind of value.
The brightnesses are guttering, weak, radiant and blazing.
the-light is a brightness that varies.
the-light is initially weak.
A lantern is in the lab.
The lantern has a brightness.
The lantern is blazing.
Fooing is an action applying to nothing.
Understand "foo" as fooing.
Instead of fooing:
showme the lantern;
showme the-light.
I introduced a testing command foo
and a new instance of the brightness kind, called the-light
, but it still isn’t an object in the world, as you can see by typing tree
:
(...)
(thedark object) (546846)
(VPH_25) (546878)
(VPH_2) (546910)
Lab (547358)
yourself
a lantern
So, again, everything is acting the way I would expect. But where is the-light
“living” in the game when I run this? Let’s see what my testing command has to say about it:
>foo
thing: lantern
"the-light" = brightness: weak
Not much, other than it does exist and is of the brightness Kind. I imagine it is in some sort of global variable space, separate from the object tree, based on the little I read about how Inform 6 works. Can someone clarify this for me?
Okay, I am going to finally get back to my original point of confusion. I am going to assign an either/or property to my value:
Lab is a room.
Brightness is a kind of value.
The brightnesses are guttering, weak, radiant and blazing.
A brightness can be adequate or inadequate.
A brightness is usually adequate.
Guttering is inadequate.
the-light is a brightness that varies.
the-light is initially weak.
A lantern is in the lab.
The lantern has a brightness.
The lantern is blazing.
Fooing is an action applying to nothing.
Understand "foo" as fooing.
Instead of fooing:
showme the lantern;
showme the-light.
I saw something different in the tree this time:
(...)
(thedark object) (547421)
(VPH_25) (547453)
(VPH_2) (547485)
(VPH_23) (547517)
Lab (547965)
yourself
a lantern
A new VPH_23 object? Did adding the property to the enumerated value just turn the-light
into an object in the object tree? Maybe the line between values and objects is even blurrier than I initially imagined? Does anyone know why this happened? Or what this VPH_23 object is?