Changing the description of a kind

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.

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

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.

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

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

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

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.

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.

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

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

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.