Changing the description of a kind

Authoring Inform 7
1

Say I have a kind of thing, like a button. I can set the kind’s printed name and description just fine, and it applies to all objects of that kind.

A button is a kind of device with printed name "button" and description "A green button."

Can I change the printed name or description later? All my attempts seem to fail.

2

The kind is like a cookie-cutter with which individual objects are created, so once objects are created, altering the cookie-cutter won’t change the properties of objects already made.

Furthermore, Inform doesn’t appear to have a direct syntax for bulk updates of anything other than either-or properties. So for example it is possible to write

now every button is switched on.

but there is no equivalent example in the documentation for other sorts of property, and I can’t make one work either. In particular the obvious syntax

now the description of every button is "A red button".

doesn’t compile.

The closest might be a loop repeating through every instance of a kind:

repeat with item running through buttons:
	now the description of the item is "A red button";
2 Likes
3

Thanks! That makes sense. Nice to see I wasn’t missing anything obvious. I thought about changing a global value, and putting an if/else inside the name and description, but the loop idea is very cool too.

4

You can do this if you define a sentence verb.

The verb to is-described-as means the description property.

   [...]
   now every thing is-described-as "Boop.";

EDIT-ADD: (Yes, “the verb to is-described-as” is clunky. The language kind of wants an infinitive there, but I couldn’t come up with one. Maybe “the verb to desc-display”.)

3 Likes
5

However, to dynamically change the description of a kind, it’s probably better to write a “Check examining a button” rule. Or maybe “Check examining a button when…” That way you can have any logic you want in there.

1 Like
6

That is really cool :+1:t2:
Thanks.

I see verbs-used-to-mean-properties in order to update them is mentioned in §15.12 in the documentation

7 
The verb  to be described as means the description property.

or

The verb to have a description of means the description property.

both seem to work without confusing the compiler.

8

I do not trust that use of “description”, “described”, or “has/have” as words will never confuse the compiler. I use hyphenated phrases to avoid potential problems.

9

Fair enough.

While testing this I came upon this odd apparent bug, which I can’t work out even after looking through the I6 code, which looks fine to me.

The following:

The Control Room is a room.	
A button is a kind of device with printed name "button" and description "A green button."
The large button, the small button and the medium button are buttons in the Lab. The printed name of the large button is "large button".The printed name of the medium button is "medium button".The printed name of the small button is "small button".
When play begins:
	say "Start state: Large: [description of the large button]; Medium: [description of the medium button]; Small: [description of the small button].";
	repeat with item running through buttons:
		say "Starting iteration through [item]: Large: [description of the large button]; Medium: [description of the medium button]; Small: [description of the small button].";
		now the description of the item is "A red button";
		say "After [item] update: Large: [description of the large button]; Medium: [description of the medium button]; Small: [description of the small button].";
		now every button is-described-as "A yellow button";
		say "After every item update: Large: [description of the large button]; Medium: [description of the medium button]; Small: [description of the small button].";
	say "End state: Large: [description of the large button]; Medium: [description of the medium button]; Small: [description of the small button].";

The verb to is-described-as means the description property.

leads to the following odd output:

Start state: Large: A green button.; Medium: A green button.; Small: A green button..
Iteration through large button: Large: A green button.; Medium: A green button.; Small: A green button..
After large button update: Large: A red button; Medium: A green button.; Small: A green button..
After every item update: Large: A yellow button; Medium: A yellow button; Small: A yellow button.
Iteration through small button: Large: A yellow button; Medium: A yellow button; Small: A yellow button.
After small button update: Large: A red button; Medium: A red button; Small: A red button.
After every item update: Large: A red button; Medium: A red button; Small: A red button.
Iteration through medium button: Large: A red button; Medium: A red button; Small: A red button.
After medium button update: Large: A red button; Medium: A red button; Small: A red button.
After every item update: Large: A red button; Medium: A red button; Small: A red button.
Large: A red button; Medium: A red button; Small: A red button.

any ideas?

1 Like
10

OK, I’ve worked out what’s happening- 'now every button is-described-as “A yellow button” points the description property of every button to an identical constant packed stored text. in this routine:

[ Prop_2 
    x ! internal use only
    x_ix ! internal use only
    qcy_0 ! internal use only
    qcn_0 ! internal use only
    ;
    ;
    qcy_0 = 0;
    qcn_0 = 0;
    for (x=IK16_First: x: x=x.IK16_Link){
        qcn_0++;
        x.p7_description = TX_L_86;
        qcy_0++;
    }
    if (qcy_0 == qcn_0){
    }
];

......

Constant TX_PS_86 = "A yellow button";
Array TX_L_86 --> CONSTANT_PACKED_TEXT_STORAGE TX_PS_86;

When a button is then assigned a new description of “A red button”, rather than pointing that one button to the new constant stored text, the stored text reading “A yellow button” is overwritten with a copy of “A red button” by the function below, so the descriptions of all buttons immediately change to red.

BlkValueCopy(GProperty(10, tmp_0,description), TX_L_81);

.......

Constant TX_PS_81 = "A red button";
Array TX_L_81 --> CONSTANT_PACKED_TEXT_STORAGE TX_PS_81;

After which TX_L_86 reads as “A red button”

Furthermore, on subsequent encounters with 'now every button is-described-as “A yellow button” nothing changes, because the descriptions already point to the constant stored text (TX_L_86) that used to be “A yellow button” but is now “A red button”.

1 Like
11

After looking at this again in more detail, more compiler weirdness emerges about how text properties are assigned differently in I6 by the following three syntaxes for assertion in I7:

now the description of the large button is "A red  button".

translates into I6 as

BlkValueCopy(GProperty(10, tmp_0,description), TX_L_81);

.

now the large button is-described-as "A red button".

translates into I6 as

tmp_0.p7_description = BlkValueCopy(I7SFRAME, TX_L_81);

.
and (leaving aside the loop code)
.

now every button is-described-as "A red button".

translates into I6 as

x.p7_description = TX_L_81;

The essential difference between the first syntax and the second and third is that the first overwrites the text pointed to by the description property without altering the pointer, whereas the second and third leave the text originally pointed to by the description property unchanged but change the description property pointer to point to a different text- in the second case to a copy made elsewhere of the original text literal “A red button”, in the third case directly to the original text literal itself.

There is a further subtlety in the operation of the second syntax, in that there is a separate copy made for each line of I7 using it, but if the same line is returned to, e.g. in a repeat loop, the same copy is reused, meaning that (like in the third syntax) the description properties of multiple objects referenced in a loop will all end up pointing to the same text in memory- and if this is subsequently overwritten by a change to the description property of any one of those objects by means of the first syntax, the descriptions of all the objects will change in parallel.

What this means in practice is that unless these idiosyncrasies create the effect you’re looking for, you must be careful about mixing up assertions of text property values using the conventional ‘now the (property) of (object) is (text)’ with assertions using verbs derived from ‘To (verb) means the (property) property’. Sticking to one or the other with a given text property type will work fine.

Because of the different way assertions are translated into I6, properties with numerical values don’t have these problems (including enumerated values created with ‘(property) is a kind of value’) -with these you can mix the methods of assertion with impunity, including when asserting them to be equal to variables.

EDIT- PS I haven’t tested this with other kinds of value such as lists or table names, but suspect these might cause problems similar to texts, being represented by block values in I6.

EDIT- V10 has changed things slightly, in that the loop evoked by now every.... now calls BlkValueCopy() e.g.

 x.description = BlkValueCopy(I7SFRAME, bc_U191)

but while this refreshes the set of pointers in the relevant description properties each time the loop runs to point to a fresh copy of a text (in this case of bc_U191), it remains the case that each cycle of the loop recycles the same pointer (as described for Syntax 2 above) so the effect remains that all descriptions point to the same copy of text and updating any one of them with now the description of ... is ... will unexpectedly update them all.

It remains the case that exclusively using the allocated verb to update the descriptions, either singly or as a group, will work as expected, as long as this is not mixed with the standard now the (text property) of (object) is (text) syntax.