Roger Firth's IF pages
InFancy -- using Inform objects

Intro Header Body Properties/attributes Names Listings Descriptions Classes Dynamic objects The game

Unlike the single-line header, the body of an object usually occupies at least three or four lines; thirty or forty lines is common, and three or four hundred isn't unheard-of. But that's advanced stuff: our aspirations at this stage are much more modest -- understand the permitted syntax.

Body segments

Just as we divided the overall object definition into a header and a body, it's useful to subdivide the body into segments. There are four possible segments; they're all optional, and often only one or two are needed. The segments can occur in any order; each is introduced by a keyword:

Object    header_data
  class   ...    ! inheritance classes
  with    ...    ! public properties
  private ...    ! private properties
  has     ...    ! attributes flags
          ;

The term header_data represents the name/relationship material that we covered on the previous page; hopefully you now know what that all means. Next, we'll summarise the use of the four segments types.

"class" segment

The class keyword introduces a space-separated list of class names from which this object inherits parts of its definition.

class class_iname  class_iname ... class_iname

This won't make much sense until we've talked about class definitions, so we'll leave the details of the class segment until later. To be going on with, here's an example:

Object  kitchen_table "table"
  class Furniture
        ... ;

"with" segment

The with keyword introduces a comma-separated list of the object's (public) property variables.

with  property_def, property_def, ... property_def

Here, each property_def represents a variable which is associated with this object, and therefore consists of a prop_name and (optionally) an initial value. In fact, you can have:

• no initial value -- the prop_name is a scalar variable initialised to zero
• one initial value -- the prop_name is a scalar variable initialised to that value
• a space-separated list of initial values -- the prop_name is a word array initialized to those values

That is, for each property_def in the with syntax definition, you can substitute any of:

prop_name
  or
prop_name  value
  or
prop_name  value  value ... value

Finally, each value in this definition can be anything that can be evaluated at compile-time:

number
  or
'dictionary_word'
  or
"string"
  or
[; statement; statement; ... statement; ]

The next page has more to say about the use of properties, but here's a short example:

Object  kitchen_table "table"
  with  name 'battered' 'pine' 'table',
        description "The table is scuffed and stained with indeterminate substances.",
        ... ;

"private" segment

The private keyword introduces a comma-separated list of the object's internal (private) property variables.

private  property_def, property_def, ... property_def

The structure of the private segment is exactly the same as the with segment, and in fact the only difference between the two is that the property_def settings in a with segment are accessible from other objects, while those in a private segment can be accessed only by its own object. It turns out that this distinction is of minimal value in most games, and the majority of authors never feel the need to use private properties. Follow their lead, sez I.

"has" segment

The has keyword introduces a space-separated list of true/false (on/off, present/absent, set/unset) flags associated with the object.

has  attribute_def  attribute_def ... attribute_def

Each attribute_def is either an attr_name (which sets that flag value to true), or ~attr_name (which sets the flag to false).

The next page has more to say about the use of attributes, but here's a short example:

Object  kitchen_table "table"
  has   static supporter
        ... ;

The (almost) complete object syntax

We've mentioned the various elements making up an object definition; now's the time to summarise what we've said so far. The commonly-found and generally useful syntax of an object is something like:

Object  set_of_arrows iname "xname" parent_iname
  class class_iname  class_iname ...  class_iname
  with  prop_name value,
        prop_name value,
        ...
        prop_name value
  has   attr_name  attr_name ...  attr_name;

Notes

1. The definition starts with Object and ends with ;
2. All four header_data items are optional. You can't use both set_of_arrows and parent_iname
3. The private segment (which occurs very rarely) has been omitted from this explanation
4. The class segment (which defines inheritance classes), the with segment (which defines property variables) and the has segment (which defines attribute flags) are all optional, and can occur in any order
5. For each property variable, the prop_name is usually followed by a single value (a number, a string, a routine, etc) but can be followed by a space-separated list of values, or by nothing
6. For each attribute flag, the attr_name can be prefixed by a tilde (~) to turn off the flag. Since they're off by default, you'll usually do this only to cancel an attribute which was set by the object's class
7. In general, spaces are used to separate the various items within an object definition. The only exception is the comma (,) which separates one property_def from the next. Specifically, you don't need to use commas in the header_data, or in the class or has segments

Phew! Spelling out the object syntax is a bit of a hard slog, but it's important to be confident with what's allowed. Next, we talk some more about properties and attributes.

Intro Header Body Properties/attributes Names Listings Descriptions Classes Dynamic objects The game