Showme command does not display objects properly

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.

well, the post in showme vs. showobj is now obsolete, with r10, Inform 7 is now open source…

on the specific issues, I feel that indeed is perhaps a bug, esp. the second one.

OTOH, tried showme/showobj under inform r10 ?

Best regards from Italy,
dott. Piergiorgio.

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.

-Wade

4 Likes

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.

7 Likes

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.

Thanks for your input.

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.

4 Likes

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.

and now showme foo would work.

2 Likes

Okay, I understand enough now to understand that I understand nothing about how Inform works :slight_smile: .

I won’t file a bug and I’m writing my own test commands. Thanks.

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.

6 Likes

yeah, that’s a better approach. :grinning: