I thought the showme command would be a good way to display the contents of objects at run time but I ran into a couple of problems.
Code for first problem:
Lab is a room.
A gizmo is an object.
A gizmo has text called a name.
The name of the gizmo is "the thingie".
Results:
>showme gizmo
gizmo - thing
location: out of play
unlit, inedible, portable; singular-named, improper-named
description: none
initial appearance: none
printed name: "gizmo"
printed plural name: none
indefinite article: none
list grouping key: none
name: "the thingie"
The showme command appears to be printing the information about an object like it is a thing.
Code for second problem:
Lab is a room.
A widget is a kind of object.
A gizmo is a widget.
A gizmo has text called a name.
The name of the gizmo is "the thingie".
Results:
>showme gizmo
There seems to be no such object anywhere in the model world.
So, it appears that the showme command is not as useful as I thought it would be to show me the contents of an object at runtime. Which is okay. I can write my own testing command to do this.
My first question is: is this a bug?
I also searched the posts and found information in the showme vs showobj post:
Which leads to a more important question: If it is a bug, is it worth reporting? There doesnât appear to be a way to fix it.
I admit I was a bit freaked out by your demo code where you made an object called a gizmo. Because a gizmo definitely sounds like something thatâs going to be in the gameworld. i.e. a thing. Objects are the parent kind of things and rooms, and I donât know how much use there is in creating them for new abstract purposes. But my judgment is irrelevant.
The upshot is, as you found out, what SHOWME does is hardcoded.
Hopefully, you could code your own test command that would show you the thing you want to see?
Re: second problem, I think this stems from you creating a kind of object. Again objects are kind of weird as a thing to be directly addressed. You can make the gizmo accessible to your typing by adding 'Understand âgizmoâ as gizmo", which suggests there is some irregularity (maybe intentional) in adding a grammar token to it. Why there wasnât in the first example, Iâm not sure, but again, if you havenât assigned the gizmo to be a room or a thing yet, I donât know if Inform is also left in the dark at this point, or is just pining to make an assumption.
An example: back in example one, if you add âgizmo is north of labâ, then Inform makes it a room.
In summary, I think you can probably make a test command to do what you want, but Iâd also want to make sure itâs worth trying to work at this high level of just The Object in the first place.
SHOWME isnât lying. gizmo is a thing. I7 doesnât let you make instances of objects, per se. Saying gizmo is an object is an invitation to the compiler to infer what subkind of object that gizmo is. If thereâs not a compelling indication otherwise, it ends up a thing (but it could even end up a room depending on the subsequent assertions).
You can say abstraction is a kind of object and gizmo is an abstraction, and then gizmo wonât be a thing.
This is also true for the other kinds. You can say:
foo is a vehicle.
foo is a container.
foo is a thing.
foo is an object.
in any order and itâll compile. You just canât assert something about foo that fails to be internally consistent with the other assertions.
Sorry for the confusion. I meant it just to be a placeholder word, like âfooâ, âbarâ or âbazâ. Itâs just test code to understand how the showme command works.
Iâm trying to create something similar to an OOP Object. It doesnât exist as a Thing in the world model. Isnât that what an Object is? Maybe not, it wouldnât be the first time I have mistranslated a programming concept in Inform.
Yes, I had to dig a bit more but I think I found the source code and issue tracker I need at this github repository.
There are so many pieces to the new open source project I am losing track of them all. So maybe this is where I could file a bug if it does turn out to be a bug.
Wade had it right⌠by making it a subkind of object and not something thatâs a region, room, direction, or thing, youâd need your own explicit Understand line for the parser to handle it. And though showme doesnât correspond to an action, per se, itâs still the case that the parser has to resolve its parameter. You canât use showme with a privately-named thing either.
Thereâs an I7 bug tracker but I have a lot of confidence you would be told that all of this is expected behavior and not a bug.
Okay, yeah, then the behavior of the showme command makes sense.
The idea that Inform would turn an Object into a Thing when I explicitly declared it as an Object never even entered my mind.
Yes, and that is the second example I provided. And, again, I suppose the response that showme gives, which is "There seems to be no such object anywhere in the model world.", isnât wrong since the kind of object I am using doesnât exist in the model world. Itâs just not what I expected. I expected it to print out the same collection of properties that it does for every other subtype of Object.
Youâre giving the error message too much credit. Itâs not about non-existence in the model world, itâs really about non-existence in the grammar tokens. This is a decent compromise that wouldnât need Understand lines on a per instance basis:
Abstraction is a kind of object.
foo is an abstraction.
Section foo finder (not for release)
understand the printed name property as describing an abstraction.
Yeah, the trick with using bare objects (as opposed to the more fully-implemented kinds like things, rooms, and directions) is that they have basically no behavior built into them by default. Which is usually a good thing: the reason to use a bare object is because you donât want all those built-in assumptions. For example, Inform doesnât automatically fill in the properties that let them be understood by the parser.
But, you can change that if you want! Hereâs the relevant bit from the Standard Rules:
A thing can be privately-named or publicly-named.
A thing is usually publicly-named.
âPublicly-namedâ means the parser should recognize it by its source code name, even if you donât write any Understand lines.
So you can do exactly this for your own kind of object as well:
An abstraction is a kind of object.
An abstraction can be privately-named or publicly-named.
An abstraction is usually publicly-named.
And voilĂ ! Now your abstractions can be parsed in commands, and SHOWME works as expected.