Inform: A brief note on encapsulation

I need to recap earlier chapters, but I’m currently reading the chapter on Advanced Actions and this bit just grabbed me in that “just blog this immediately” sort of way.

12.10. Action variables

And we will want the photographing action to have the player use the best-quality camera which comes to hand. We will give the action a variable called the ‘camera photographed with’, thus:

The photographing action has an object called the camera photographed with.

Every action’s variables must be named differently from those of all other actions, because there are some “before” rules (for instance) which take effect for many different actions, and which might need access to any of their variables. So action variables should be named in a way marking out to which action they belong. The best way to do this is to include the past participle of the action name – just as “camera photographed with” contains the past participle “photographed” of the action “photographing”.

A stuffy OOP programmer could look down his nose at this – why, you’re asking me to simply¬†name global variables with an identifier???!?! What about encapsulation?!!!

And yet, the solution results in totally reasonable, fully comprehensible English. After all, language isn’t encapsulated. Oh, sure, there are some things we understand best within a particular context, or meanings that change depending on context. But nothing’s stopping me from referring to calipers while in a kitchen. The English language has no mechanism for programming’s encapsulation, and yet somehow we get by.

Inform: Things, Kinds, and other Words Of Very Definite Meaning

Inform’s definitions make me pause. I want to write a short post summarizing some main ideas: Things, which are sort of like objects; Kinds, which are sort of like classes; Actions, which are sort of like, well, functions with side effects; Values, which I guess are also like objects? Or instances? Or just values?

If I were learning nearly any other programming language, this uncertainty would be non-existent. Even when things are non-standard I could say things like, “Oh, well Lua can do objects but it implements them unusually via tables.” I think the reason I feel so uncertain here is that Inform is under no pretense of writing a manual aimed at programmers.

Here’s a fantastic example, from the start of the chapter of Writing with Inform on “Kinds”:

4.1. New kinds

Values are to Inform what nouns are to English sentences. They represent numbers, times of day, pieces of text, places, people, doors, and so on. Because they have such an enormous variety, and because we often want to talk about what some of them have in common, we need a way to sort all of these different ideas out. That’s the main aim of Inform’s concept of “kind”.

I’m all well and good with what nouns are, but the programmer part of me wants to scan for words like “variable”, “object”, “constant”, or even “type”. Inform avoids these programmerly terms with such consistency that it simply can’t be an accident. It’s like the authors are saying, “Look, we talk about kinds of things because that’s the kind of thing that people understand. If we go on about classes somebody’s going to think they’re going to be assigned homework and start having flashbacks of that final exam they failed in tenth grade, and we can’t have that.”

The other reason for caution is that Inform isn’t doing things the way I’m used to. It’s not primarily a procedural language, but a rule based one. Rather than defining a main loop and writing interface code and programming logic in sequence, you simply define what exists and what rules govern the way things relate to each other.

visual index of an Inform project
The index that Inform generates for your project gives a good high-level idea of how it defines and classifies your code.

So I’m tempted to compare Inform’s ‘kinds’ to classes. But there are important caveats. Kinds aren’t meant to visually encapsulate or organize code in the way that object-oriented programming usually does. You can define verbs and relationships that act on particular kinds of objects, but those definitions exist wherever you decide to put them in your story file. Verbs in this case are sort of like a class method, but verbs themselves aren’t ‘attached’ to a class. It reminds me a bit of how Common Lisp handles methods, where the objects in question still have to be passed as parameters because of the list structure of CL code. In a sense CL methods are simply functions defined for a particular class of parameter. Similarly, Inform code can have verbs defined to operate on a particular kind of noun.