kinds of value vs the docs

Authoring Inform 7
21

Just so you know, you can give kinds and things properties with multiple values:

The Lab is a room.

The job board is a supporter in the lab.

A thing can be readable or unreadable.
A thing is usually unreadable.

A job posting is a kind of readable thing.
A job posting can be accepted, pending or unaccepted.

job98278 is an unaccepted job posting on the job board.
The printed name is "Job #98278".
The description is "I need help. Please help me. Look for me in the well on the farm at the end of the road north from town. ([the job posting condition of job98278])".
Understand "job/-- 98278" as job98278.

job44313 is an unaccepted job posting on the job board.
The printed name is "Job #44313".
The description is "Help wanted. Larceny. Murder. General Thuggery. See Fred at the Garrotted Goblin for details. ([the job posting condition of job98278])".
Understand "job/-- 44313" as job44313.

Instead of taking a job posting:
	if the noun is accepted:
		say "You already accepted that job.";
	otherwise if the noun is pending:
		say "That job is pending.";
	otherwise:
		now the player carries the noun;
		now the noun is accepted;
		say "You accept the job."

test me with "x job board / read 98278 / read 44313 / take job 98278 / i / read job 98278".

No problem getting “accepted,” “unaccepted,” or “pending” to compile.

22

Interesting that it compiled. I guess the difference is the values of a kind vs. the values of an object.

23

I doubt that. There is no difference between a property of a kind and a property of an object. Either way you just have a new kind of value with 3 or more possible values.

One difference with your way is that you gave the kind of value a name. (Status is a kind of value. A job posting has a status. instead of A job posting can be...) I don’t think that should cause a problem either though…

Based on your original error message, it seems like it’s not recognizing “unaccepted” as an adjective that can apply to “the job posting”. But I’m not sure why that would be the case. I assume it works if you comment out just the one sentence with the error, right? If that’s the case, it can’t be that “status” or “unaccepted” has a different definition elsewhere; and job posting has a status should mean that the values of “status” can be used as adjectives.

1 Like
24

What I meant was that one can assign values to either objects or to kinds of objects.
I was able to compile phrases like “A job posting is accepted” but then had trouble when I used it; e.g. “If job posting is accepted…”
It always worked if I said “Status of job posting is accepted.” and then “If status of job posting is accepted:” I guess there is some crack when the parser is trying to make the shortcut.

25

Yeah, like I said, for some reason it’s not recognizing “unaccepted” as an adjective that can apply to the job posting.

26

Not to horse a dead beat, but I got intrigued by this discussion and had to find out what was going on. I started with the code Al posted in a brand new, empty project, with only the addition of a room and establishing that things can be readable:

A job posting is a readable thing on the job board. 
Status is a kind of value. The Statuses are accepted, pending, or unaccepted.
A job posting has a status. The job posting is unaccepted.

I got the same error Al reported. The message tells us were the problem is, so the next step is to comment out that assertion and see what happens. The game compiles, so we can look at the index to see what we can see. The map shows us there’s a job board in the lab, and a job posting on the board. Expanding the job posting shows us it’s a thing and it’s readable, but it doesn’t show a status property (which seems wrong).

If we look in the Kinds Index we see that “status” is defined as a kind, there are three values, and the default value is “accepted.” The details show us that “status” is a value, and the three possible statuses are “accepted,” “pending,” or “unaccepted.”

If we go back to the story screen and type the command “SHOWME job posting” we see that the job posting has a status property, and its value is “accepted.” This tells us that Inform doesn’t have a problem with the values we’re defining for the kind of value, or the name we’re giving to the kind of value. It isn’t even balking at our assertion that the job posting has a property tied to our kind of value. So, now we need to see if the assertion statement works with any of the values.

If we change the assertion to “The job posting is accepted.” the game compiles. If we change the assertion to “The job posting is pending.” the game compiles. We only get the error when we try to assert that the job posting is “unaccepted.” The next step is to see if the issue is the word “unaccepted” or that it’s the last value listed. If we switch “accepted” and “unaccepted” and try to compile the game with “The job posting is unaccepted.” the game compiles, telling us that the problem is related to the list of values.

According to Al’s post, he’s copying from an example in the documentation, citing this line:

Brightness is a kind of value. The brightnesses are guttering, weak, radiant and blazing.

This is what the index shows when we compile the game with Brightness defined:

image

However, there are differences between the line in the documentation, and the line Al wrote. Chiefly, as @BadParser pointed out, Al used “or” instead of “and” in his statement. When we make that change and run the game… the game compiles and the job posting has a status of unaccepted. Now we’re left wondering why AND is so important. Well, it turns out, there was a bit of a clue in the index.

Here is a screenshot of the details of the Status kind of value in the index as Al originally wrote it:

image

And here is a screenshot of the details after changing OR to AND:

image

This is a clear indication that OR cannot be used in the list of values assigned to a kind of value. That means this might be a bug–you’re supposed to be able to do that, but can’t. Or, it’s intended and the documentation probably needs to warn people.

If we need more proof that this won’t work, remove the serial comma from Al’s original line and check out what happens in the index:

image

So, the error was occurring because we were trying to assign a value to a property, the property is tied to an enumerated value (kind of value), and the value we were trying to assign wasn’t a valid value. The valid values were “accepted”, “pending”, and “or unaccepted”.

Remember. The index is your friend!

Addendum:

An even more curious thing. In my previous post I used a multi-value property, and the list of values was provided with OR (and without a serial comma). If you look at the index with that code you find Inform has created a kind of value called “job posting condition” with the values: “accepted, pending, unaccepted”. (See WI 4.10 Conditions of things.)

9 Likes
27

Wow! Thank you very much. You pulled back Inform’s robe for this one. I did a lot of what you did but I didn’t catch the “or accepted” in the index. Thanks for the tip. I will use AND for all my enums going forward.

Ironically, I now need to change job posing as a thing to a kind. Stepping off the platform again…

1 Like