~ubuntu-branches/ubuntu/gutsy/inform/gutsy

<TR><TD Valign="top"><A HREF="contents.html">Contents</A> <A HREF="section2.html">Back</A> <A HREF="chapter2.html">Forward</A><TD bgcolor="#F5DEB3"><BLOCKQUOTE><H3>3. The language of objects</H3></BLOCKQUOTE><TR><TD><TD>

Objects make up the substance of the world. That is why

they cannot be composite.

...Ludwig Wittgenstein (1889--1951), Tractatus</BLOCKQUOTE>

<HR><BLOCKQUOTE><H3>3.1. Objects and communication</H3></BLOCKQUOTE>

The objects in a program are its constituent parts: little lumps of code

and data. The starting point of an "object-oriented language'' is that

it's good design to tie up pieces of information in bundles with the pieces

of program which deal with them. But the idea goes further:

1. -- An object is something you can communicate with. (It's like a

company where many people work in the same building, sharing the same

address: to the outside world it behaves like a single person.)

2. -- Information inside the object can be kept concealed from the

outside world (like a company's confidential files). This is sometimes

called "encapsulation''.

3. -- The outside world can only ask the object to do something, and

has no business knowing how it will be done. (The company might decide to change

its stock-control system one day, but the outside world should never even

notice that this has happened, even though internally it's a dramatic shift.)

All three principles have been seen already for routines:

(1) you can call a routine, but you can't call "only this part of a routine'';

(2) the local variables of a routine are its own private property, and the

rest of the program can't find out or alter their values; (3) as long as the

routine still accomplishes the same task, it can be rewritten entirely and the

rest of the program will carry on working as if no change had been made.

Why bother with all this? There are two answers. First and foremost,

Inform was designed to make adventure games, where objects are the right

idea for representing items and places in the game. Secondly, the 'object'

approach makes sense as a way of organising any large, complicated

program.

The other key idea is communication. One can visualise the program as being

a large group of companies, constantly writing letters to each other to

request information or ask for things to be done. In a typical "message'',

one object A sends a detailed question or instruction to another object B,

which replies with a simple answer. (Again, we've seen this already for

routines: one routine calls another, and the other sends back a return value.)

Routines are only one of the four basic kinds of Inform object, which are:

-- routines, declared using <TT>[</TT>...<TT>]</TT>;

-- strings in double-quotes <TT>"like so"</TT>;

-- collections of routines and global variables, declared using <TT>Object</TT>;

-- prototypes for such collections, called "classes'' and declared using

<TT>Class</TT>.

These four kinds are called "metaclasses''. If <TT>O</TT> is an object, then the

function

<PRE>

metaclass(O)

</PRE>

will always tell you what kind it is, which will be one of the four values

<PRE>

Routine String Object Class

</PRE>

For example,

<PRE>

metaclass("Violin Concerto no. 1")

</PRE>

evaluates to <TT>String</TT>, whereas

<PRE>

metaclass(Main)

</PRE>

should always be <TT>Routine</TT> (since <TT>Main</TT> should always be the name of the

routine where an Inform program begins to run). From <A HREF="section1.html">Section 1</A> we already know

about metaclasses <TT>Routine</TT> and <TT>String</TT>, so it's the other two cases which

this section will concentrate on.

<TR><TD Valign="top"><IMG SRC="icons/ddbend.gif" ALT="/\/\"><TD bgcolor="#EEEEEE"> Why only these four kinds? Why are strings objects, and not (say)

variables or dictionary words? Object-oriented

languages vary greatly in to what extreme they take the notion of object: in

the dogmatic Smalltalk-80, every ingredient of any kind in a program

is called an object: the program itself, the number 17, each variable and

so on. Inform is much more moderate. Routines, <TT>Object</TT>s and classes

are genuinely object-like, and it just so happens that it's convenient to

100

treat strings as objects (as we shall see). But Inform stops there.

101

102

103

104

<HR><BLOCKQUOTE><H3>3.2. Built-in functions 2: the object tree</H3></BLOCKQUOTE>

105

Routines, strings and (as we shall see) classes are scattered about in an

106

Inform program, in no particular order, and nothing links them together.

107

<TT>Object</TT> objects are special in that they are joined up in the "object tree''

108

which grows through every Inform program.

109

110

111

In this tree, objects have a kind of family relationship to each other: each

112

one has a parent, a child and a sibling. (The analogy here is with family

113

trees.) Normally such a relation is another object in the tree, but instead

114

it can be

115

<PRE>

116

nothing

117

</PRE>

118

119

which means "no object at all''. For example, consider the tree:

120

<PRE>

121

Meadow

122

123

Mailbox -> Player

124

! !

125

Note Sceptre -> Cucumber -> Torch -> Magic Rod

126

127

Battery

128

</PRE>

129

130

The <TT>Mailbox</TT> and <TT>Player</TT> are both children of the <TT>Meadow</TT>, which is their

131

parent, but only the <TT>Mailbox</TT> is the child of the <TT>Meadow</TT>.

132

The <TT>Magic Rod</TT> is the sibling of the <TT>Torch</TT>, which is the sibling of the

133

<TT>Cucumber</TT>, and so on.

134

135

136

137

Inform provides special functions for reading off positions in the tree:

138

<TT>parent</TT>, <TT>sibling</TT> and <TT>child</TT> all do the obvious things, and in addition

139

there's a function called <TT>children</TT> which counts up how many children an

140

object has (where grandchildren don't count as children). For instance,

141

<PRE>

142

parent ( Mailbox ) == Meadow

143

children ( Player ) == 4

144

child ( Player ) == Sceptre

145

child ( Sceptre ) == nothing

146

sibling ( Torch ) == Magic Rod

147

</PRE>

148

149

150

It is a bad idea to apply these functions to the value <TT>nothing</TT> (since it is

151

not an object, but a value representing the absence of one). One can detect

152

whether a quantity is a genuine object or not using <TT>metaclass</TT>, for

153

<PRE>

154

metaclass(X)

155

</PRE>

156

157

is <TT>nothing</TT> for any value <TT>X</TT> which isn't an object: in particular,

158

<PRE>

159

metaclass(nothing) == nothing

160

</PRE>

161

162

163

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> Hopefully it's clear why the tree is useful for writing adventure

164

games: it provides a way to simulate the vital idea of one thing being

165

contained inside another. But even in non-adventure game programs it can

166

be a convenience. For instance, it is an efficient way to hold

167

tree structures and linked lists of information.

168

169

170

171

<HR><BLOCKQUOTE><H3>3.3. Creating objects 1: setting up the tree</H3></BLOCKQUOTE>

172

The object tree's initial state is created with the directive <TT>Object</TT>. For

173

example,

174

<PRE>

175

Object "bucket" ...

176

Object -> "starfish" ...

177

Object -> "oyster" ...

178

Object -> -> "pearl" ...

179

Object -> "sand" ...

180

</PRE>

181

182

(where the bulk of the definitions are here abbreviated to "<TT>...</TT>''),

183

sets up the tree structure

184

<PRE>

185

"bucket"

186

187

"starfish" --> "oyster" --> "sand"

188

189

"pearl"

190

</PRE>

191

192

The idea is that if no arrows <TT>-></TT> are given in the <TT>Object</TT> definition, then

193

the object has no parent: if one <TT>-></TT> is given, then the object is a child of

194

the last object to be defined with no arrows; if two are given, then it's a

195

child of the last object defined with only one arrow; and so on. (The list

196

of definitions looks a little like the tree picture turned on its side.)

197

198

199

An object definition consists of a "head'' followed by a "body'', which is

200

itself divided into "segments'' (though there the similarity with caterpillars

201

ends). The head takes the form:

202

203

<TT>Object </TT><arrows> <name> <TT>"textual name"</TT> <parent>

204

</BLOCKQUOTE>

205

206

but all of these four entries are optional.

207

1. -- The <arrows> are as described above. Note that if one or more

208

arrows are given, that automatically specifies what object this is the child

209

of, so a <parent> cannot be given as well.

210

2. -- The <name> is what the object can be called inside the program;

211

it's analogous to a variable name.

212

3. -- The <TT>"textual name"</TT> can be given if the object's name ever needs

213

to be printed by the program when it is running.

214

4. -- The <parent> is an object which this new object is to be a child

215

of. (This is an alternative to supplying arrows.)

216

217

So much is optional that even the bare directive

218

<PRE>

219

Object;

220

</PRE>

221

222

is allowed, though it makes a nameless and featureless object

223

which is unlikely to be useful.

224

225

226

<HR><BLOCKQUOTE><H3>3.4. Statements for objects: move, remove, objectloop</H3></BLOCKQUOTE>

227

The positions of objects in the tree are by no means fixed: they are created

228

in a particular formation but are often shuffled around extensively during

229

the program's execution. (In an adventure game, where the objects represent

230

items and rooms, objects are moved in the tree whenever the player picks

231

something up or moves around.) The statement

232

233

234

</BLOCKQUOTE>

235

236

moves the first-named object to become a child of the second-named one. All

237

of the first object's own children "move along with it'', i.e., remain its own

238

children. For instance, following the example in <A HREF="section3.html">Section 3</A>.2 above,

239

<PRE>

240

move Cucumber to Mailbox;

241

</PRE>

242

243

results in the tree

244

<PRE>

245

Meadow

246

247

Mailbox -----------> Player

248

! !

249

Cucumber -> Note Sceptre -> Torch -> Magic Rod

250

251

Battery

252

</PRE>

253

254

It must be emphasized that <TT>move</TT> prints nothing on the screen, and indeed

255

does nothing at all except to rearrange the tree. When an object becomes the

256

child of another in this way, it always becomes the "eldest'' child in the

257

family-tree sense; that is, it is the new <TT>child()</TT> of its parent, pushing

258

the previous children over into being its siblings.

259

It is, however, illegal to move an object out of such a structure using

260

<PRE>

261

move Torch to nothing;

262

</PRE>

263

264

because <TT>nothing</TT> is not an object as such. The effect is instead achieved with

265

<PRE>

266

remove Torch;

267

</PRE>

268

269

which would now result in

270

<PRE>

271

Meadow Torch

272

! !

273

Mailbox -----------> Player Battery

274

! !

275

Cucumber -> Note Sceptre -> Magic Rod

276

</PRE>

277

278

So the "object tree'' is often fragmented into many little trees.

279

280

281

282

Since objects move around a good deal, it's useful to be able to test where

283

an object currently is; the condition <TT>in</TT> is provided for this. For

284

example,

285

<PRE>

286

Cucumber in Mailbox

287

</PRE>

288

289

is true if and only if the <TT>Cucumber</TT> is one of the direct children

290

of the <TT>Mailbox</TT>. (<TT>Cucumber in Mailbox</TT> is true, but <TT>Cucumber in Meadow</TT>

291

is false.) Note that

292

<PRE>

293

X in Y

294

</PRE>

295

296

is only an abbreviation for

297

<PRE>

298

parent(X) == Y

299

</PRE>

300

301

but it's worth having since it occurs so often.

302

303

304

305

The one loop statement missed out in <A HREF="section1.html">Section 1</A> was <TT>objectloop</TT>.

306

307

<TT>objectloop(</TT><variable-name><TT>) </TT><statement>

308

</BLOCKQUOTE>

309

310

runs through the <statement> once for each object in the tree, putting each

311

object in turn into the variable. For example,

312

<PRE>

313

objectloop(x) print (name) x, "^";

314

</PRE>

315

316

prints out a list of the textual names of every object in the tree. (Objects

317

which aren't given any textual names in their descriptions come out as "?''.)

318

More powerfully, any condition can be written in the brackets, as long as

319

it begins with a variable name.

320

<PRE>

321

objectloop(x in Mailbox) print (name) x, "^";

322

</PRE>

323

324

prints the names only of those objects which are direct children of the

325

<TT>Mailbox</TT> object.

326

327

328

<HR><BLOCKQUOTE><H3>3.5. Creating objects 2: <TT>with</TT> properties</H3></BLOCKQUOTE>

329

So far <TT>Object</TT>s are just tokens with names attached which can be shuffled

330

around in a tree. They become interesting when data and routines are

331

attached to them, and this is what the body of an object definition is for.

332

333

334

The body contains up to four segments, which can occur in any order; each of

335

the four is optional. The segments are called

336

<PRE>

337

with has class private

338

</PRE>

339

340

<TT>class</TT> will be left until later. The most important segment is <TT>with</TT>,

341

which specifies things to be attached to the object. For example,

342

<PRE>

343

Object magpie "black-striped bird"

344

with wingspan, worms_eaten;

345

</PRE>

346

347

attaches two variables to the bird, one called <TT>wingspan</TT>, the other called

348

<TT>worms_eaten</TT>. Notice that when more than one variable is given, commas are

349

used to separate them: and the object definition as a whole is ended by a

350

semicolon, as always. The values of the magpie's variables are referred to

351

in the rest of the program as

352

<PRE>

353

magpie.wingspan

354

magpie.worms_eaten

355

</PRE>

356

357

which can be used exactly the way normal (global) variables are used. Note

358

that the object has to be named along with the variable, since

359

<PRE>

360

crested_glebe.wingspan

361

magpie.wingspan

362

</PRE>

363

364

are different variables.

365

366

367

Variables which are attached to objects in this way are called "properties''.

368

More precisely, the name <TT>wingspan</TT> is said to be a property, and is said to be

369

"provided'' by both the <TT>magpie</TT> and <TT>crested_glebe</TT> objects.

370

371

372

The presence of a property can be tested using the <TT>provides</TT> condition.

373

For example,

374

<PRE>

375

objectloop (x provides wingspan) ...

376

</PRE>

377

378

executes the code <TT>...</TT> for each object <TT>x</TT> in the game which is defined with

379

a <TT>wingspan</TT> property.

380

381

382

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> Although the provision of a property can be tested, it cannot be

383

changed while the program is running. The value of <TT>magpie.wingspan</TT> may

384

change, but not the fact that the magpie has a <TT>wingspan</TT>.

385

386

387

388

389

When the above magpie definition is made, the initial values of

390

<PRE>

391

magpie.wingspan

392

magpie.worms_eaten

393

</PRE>

394

395

are both 0. To create the magpie with a given wingspan, we have to specify an

396

initial value: we do this by giving it after the name, e.g.

397

<PRE>

398

Object magpie "black-striped bird"

399

with wingspan 5, worms_eaten;

400

</PRE>

401

402

and now the program begins with <TT>magpie.wingspan</TT> equal to 5, and

403

<TT>magpie.worms_eaten</TT> still equal to 0. (For consistency perhaps there should be

404

an equals sign before the 5, but if this were the syntax then Inform programs

405

would be horribly full of equals signs.)

406

407

408

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> Properties can be arrays instead of global variables. If two or more

409

consecutive values are given for the same property, it becomes an array. Thus,

410

<PRE>

411

Object magpie "black-striped bird"

412

with name "magpie" "bird" "black-striped" "black" "striped",

413

wingspan 5, worms_eaten;

414

</PRE>

415

416

<TT>magpie.name</TT> is not a global variable (and cannot be treated as such: it

417

doesn't make sense to add 1 to it), it is an <TT>--></TT> array. This must be

418

accessed using two special operators, <TT>.&</TT> and <TT>.#</TT>.

419

<PRE>

420

magpie.&name

421

</PRE>

422

423

means "the array which is held in magpie's <TT>name</TT> property'', so that the

424

actual name values are in the entries

425

<PRE>

426

magpie.&name-->0

427

magpie.&name-->1

428

...

429

magpie.&name-->4

430

</PRE>

431

432

The size of this array can be discovered with

433

<PRE>

434

magpie.#name

435

</PRE>

436

437

which evaluates to the twice the number of entries, in this case, to 10.

438

(Twice the number of entries because it is actually the number of byte

439

array, <TT>-></TT>, entries: byte arrays take only half as much storage as word

440

arrays.)

441

442

443

444

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> <TT>name</TT> is actually a special property created by Inform. It has the

445

unique distinction that textual values in double-quotes (like the five words

446

given in <TT>magpie.name</TT> above) are entered into the game's dictionary, and not

447

treated as ordinary strings. (Normally one would use single-quotes for this.

448

The rule here is anomalous and goes back to the misty origins of Inform 1.)

449

If you prefer a consistent style, using single quotes:

450

<PRE>

451

Object magpie "black-striped bird"

452

with name 'magpie' 'bird' 'black-striped' 'black' 'striped',

453

wingspan 5, worms_eaten;

454

</PRE>

455

456

works equally well (except that single-character names like "X'' then have to

457

be written <TT>#n$X</TT>).

458

459

460

461

Finally, properties can also be routines. In the definition

462

<PRE>

463

Object magpie "black-striped bird"

464

with name "magpie" "bird" "black-striped" "black" "striped",

465

wingspan 5,

466

flying_strength

467

[; return magpie.wingspan + magpie.worms_eaten;

468

469

worms_eaten;

470

</PRE>

471

472

473

<TT>magpie.flying_strength</TT> is neither a variable nor an array, but a routine,

474

given in square brackets as usual. (Note that the Object directive continues

475

where it left off after the routine-end marker, <TT>]</TT>.) Routines which are

476

written in as property values are called "embedded'' and are mainly used

477

to receive messages (as we shall see).

478

479

480

<TR><TD Valign="top"><IMG SRC="icons/ddbend.gif" ALT="/\/\"><TD bgcolor="#EEEEEE"> Embedded routines are unlike ordinary ones in two ways:

481

1. -- An embedded routine has no name of its own, since it is referred to

482

as a property such as <TT>magpie.flying_strength</TT> instead.

483

2. -- If execution reaches the <TT>]</TT> end-marker of an embedded routine,

484

then it returns <TT>false</TT>, not <TT>true</TT> (as a non-embedded routine would). The

485

reason for this will only become clear in Chapter III when <TT>before</TT> and <TT>after</TT>

486

rules are discussed.

487

488

489

490

<HR><BLOCKQUOTE><H3>3.6. <TT>private</TT> properties and encapsulation</H3></BLOCKQUOTE>

491

492

An optional system is provided for "encapsulating'' certain properties so

493

that only the object itself has access to them. These are defined by giving

494

them in a segment of the object declaration called <TT>private</TT>. For instance,

495

<PRE>

496

Object sentry "sentry"

497

private pass_number 16339,

498

with challenge

499

[ attempt;

500

if (attempt == sentry.pass_number)

501

"Approach, friend!";

502

"Stand off, stranger.";

503

];

504

</PRE>

505

506

507

makes the sentry provide two properties: <TT>challenge</TT>, which is public,

508

and <TT>pass_number</TT>, which can be used only by the sentry's own embedded

509

routines.

510

511

512

513

<TR><TD Valign="top"><IMG SRC="icons/ddbend.gif" ALT="/\/\"><TD bgcolor="#EEEEEE"> This makes the <TT>provides</TT> condition slightly more interesting than it

514

appeared in the previous section. The answer to the question of whether

515

or not

516

<PRE>

517

sentry provides pass_number

518

</PRE>

519

520

depends on who's asking: this condition is true if it is tested in one of

521

the sentry's own routines, and otherwise false. A <TT>private</TT> property

522

is so well hidden that nobody else can even know whether or not it exists.

523

524

525

526

<HR><BLOCKQUOTE><H3>3.7. Attributes, <TT>give</TT> and <TT>has</TT></H3></BLOCKQUOTE>

527

In addition to properties, objects have flag variables attached. (Recall

528

that flags are variables which are either true or false: the flag is either

529

flying, or not.) However, these are provided in a way which is quite

530

different. Unlike property names, attribute names have to be declared before

531

use with a directive like:

532

<PRE>

533

Attribute tedious;

534

</PRE>

535

536

537

Once this declaration is made, every object in the tree has a <TT>tedious</TT> flag

538

attached, which is either true or false at any given time. The state can be

539

tested by the <TT>has</TT> condition:

540

<PRE>

541

if (magpie has tedious) ...

542

</PRE>

543

544

tests whether the magpie's <TT>tedious</TT> flag is currently set, or not.

545

546

547

The magpie can be created already having attributes using the <TT>has</TT> segment

548

in its declaration:

549

<PRE>

550

Object magpie "black-striped bird"

551

with wingspan, worms_eaten

552

has tedious;

553

</PRE>

554

555

The <TT>has</TT> segment contains a list of attributes (with no commas in between)

556

which should be initially set. In addition, an attribute can have a

557

tilde <TT>~</TT> in front, indicating "this is definitely not held''. This is

558

usually what would have happened anyway, but class inheritance (see below)

559

disturbs this.

560

561

562

Finally, the state of such a flag is changed in the running of the program

563

using the <TT>give</TT> statement:

564

<PRE>

565

give magpie tedious;

566

</PRE>

567

568

sets the magpie's <TT>tedious</TT> attribute, and

569

<PRE>

570

give magpie ~tedious;

571

</PRE>

572

573

clears it again. The give statement can take a list of attributes, too:

574

<PRE>

575

give door ~locked open;

576

</PRE>

577

578

for example, meaning "take away <TT>locked</TT> and add on <TT>open</TT>''.

579

580

581

<HR><BLOCKQUOTE><H3>3.8. Classes and inheritance</H3></BLOCKQUOTE>

582

583

Having covered routines and strings in <A HREF="section1.html">Section 1</A>, and <TT>Object</TT>s above, the fourth

584

and final metaclass to discuss is that of "classes''. A class is a kind of

585

prototype object from which other objects are copied. These other objects are

586

sometimes called "instances'' or "members'' of the class, and are said

587

to "inherit from'' it.

588

589

590

For example, clearly all birds ought to have wingspans, and the property

591

<PRE>

592

flying_strength

593

[; return magpie.wingspan + magpie.worms_eaten;

594

595

</PRE>

596

597

(attached to the <TT>magpie</TT> in the example above) is using a formula which should

598

work for any bird. We might achieve this by using directives as follows:

599

<PRE>

600

Class Bird

601

with wingspan 7,

602

flying_strength

603

[; return self.wingspan + self.worms_eaten;

604

605

worms_eaten;

606

607

Bird "magpie"

608

with wingspan 5;

609

Bird "crested glebe";

610

Bird "Great Auk"

611

with wingspan 15;

612

Bird "early bird"

613

with worms_eaten 1;

614

</PRE>

615

616

The first definition sets up a new class called <TT>Bird</TT>. Every example of a

617

<TT>Bird</TT> now automatically provides <TT>wingspan</TT>, a <TT>flying_strength</TT> routine and

618

a count of <TT>worms_eaten</TT>. Note that the four actual birds are created using

619

the <TT>Bird</TT> class-name instead of the usual plain <TT>Object</TT> directive, but this

620

is only a convenient short form for definitions such as:

621

<PRE>

622

Object "magpie"

623

with wingspan 5

624

class Bird;

625

</PRE>

626

627

where <TT>class</TT> is the last of the four object definition segments. It's just

628

a list of classes which the object has to inherit from.

629

630

631

The <TT>Bird</TT> routine for working out <TT>flying_strength</TT> has to be written in such

632

a way that it can apply to any bird. It has to say "the flying strength of

633

any bird is equal to its wingspan plus the number of worms it has eaten''.

634

To do this, it has used the special value <TT>self</TT>, which means "whatever

635

object is being considered at the moment''. More of this in the next section.

636

637

638

Note also that the <TT>Bird</TT> <TT>with</TT> specifies a <TT>wingspan</TT> of 7. This is the value

639

which its members will inherit, unless their own definitions over-ride this,

640

as the magpie and great Auk objects do. Thus the initial position is:

641

<PRE>

642

Bird Value of wingspan Value of worms_eaten

643

magpie 5 0

644

crested glebe 7 0

645

Great Auk 15 0

646

early bird 7 1

647

</PRE>

648

649

650

<TR><TD Valign="top"><IMG SRC="icons/ddbend.gif" ALT="/\/\"><TD bgcolor="#EEEEEE"> In rare cases, clashes between what a class says and what the object

651

says are resolved differently: see <A HREF="section8.html">Section 8</A>.

652

653

654

655

656

Inform has "multiple inheritance'', which means that any object can inherit

657

from any number of classes. Thus, an object has no single class; rather,

658

it can be a member of several classes at once.

659

660

661

Every object is a member of at least one class, because the four "metaclasses''

662

<TT>Routine</TT>, <TT>String</TT>, <TT>Object</TT> and <TT>Class</TT> are themselves classes.

663

(Uniquely, <TT>Class</TT> is a member of itself.) The magpie above is a member of

664

both <TT>Bird</TT> and <TT>Object</TT>.

665

666

667

To complicate things further, classes can themselves inherit from other

668

classes:

669

<PRE>

670

Class BirdOfPrey

671

class Bird

672

with wingspan 15,

673

people_eaten;

674

675

BirdOfPrey kestrel;

676

</PRE>

677

678

makes <TT>kestrel</TT> a member of both <TT>BirdOfPrey</TT> and of <TT>Bird</TT>. Informally,

679

<TT>BirdOfPrey</TT> is called a "subclass'' of <TT>Bird</TT>.

680

681

682

Given all this, it's impossible to have a function called <TT>class</TT>, analogous

683

to <TT>metaclass</TT>, to say what class something belongs to. Instead, there is a

684

condition called <TT>ofclass</TT>:

685

<PRE>

686

kestrel ofclass Class

687

</PRE>

688

689

is false, while

690

<PRE>

691

kestrel ofclass BirdOfPrey

692

kestrel ofclass Bird

693

kestrel ofclass Object

694

"Canterbury" ofclass String

695

</PRE>

696

697

are all true. This condition is especially handy for use with <TT>objectloop</TT>:

698

<PRE>

699

objectloop (x ofclass Bird) move x to Aviary;

700

</PRE>

701

702

moves all the birds to the <TT>Aviary</TT>.

703

704

705

<HR><BLOCKQUOTE><H3>3.9. Messages</H3></BLOCKQUOTE>

706

That completes the story of how to create objects, and it's time to begin

707

communicating with them by means of messages.

708

Every message has a sender, a receiver and some parameter values

709

attached, and it always produces a reply (which is just a single value). For

710

instance,

711

<PRE>

712

x = lamp.addoil(5, 80);

713

</PRE>

714

715

sends the message <TT>addoil</TT> with parameters 5 and 80 to the object <TT>lamp</TT>, and

716

puts the reply value into <TT>x</TT>. Just as properties like <TT>magpie.wingspan</TT>

717

are variables attached to objects, so messages are received by routines

718

attached to objects, and message-sending is very like making an ordinary

719

Inform function call. The "reply'' is what was called the return value

720

in <A HREF="section1.html">Section 1</A>, and the "parameters'' used to be called function call arguments.

721

But slightly more is involved, as will become apparent.

722

723

724

725

What does the lamp object do to respond to this message? First of all, it

726

must do something. If the programmer hasn't specified an <TT>addoil</TT> routine

727

for the lamp, then an error message will be printed out when the program

728

is run, along the lines of

729

<PRE>

730

*** The object "lamp" does not provide the property "addoil" ***

731

</PRE>

732

733

Not only does <TT>lamp.addoil</TT> have to exist, but it has to hold one of the

734

four kinds of object, or else <TT>nothing</TT>. What happens next depends

735

on the <TT>metaclass</TT> of <TT>lamp.addoil</TT>:

736

737

<TABLE Border><TR><TD><TT>metaclass</TT> <TD> What happens: <TD> The reply is:

738

739

<TR><TD><TT>Routine</TT> <TD> the routine is called with the <TD> the routine's return value

740

<TR><TD> <TD> the given parameters

741

<TR><TD><TT>String</TT> <TD> the string is printed, followed <TD> <TT>true</TT>

742

<TR><TD> <TD> by a new-line

743

<TR><TD><TT>Object</TT> <TD> nothing <TD> the object

744

<TR><TD><TT>Class</TT> <TD> nothing <TD> the class

745

<TR><TD><TT>nothing</TT> <TD> nothing <TD> <TT>false</TT>, or 0, or <TT>nothing</TT>

746

<TR><TD> <TD> <TD> (all different ways of writing 0)

747

</TABLE>

748

749

750

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> If <TT>lamp.addoil</TT> is a list rather than a single value then the

751

first entry is the one looked at, and the rest are ignored.

752

753

754

755

For example,

756

<PRE>

757

print kestrel.flying_strength();

758

</PRE>

759

760

will print out 15, by calling the <TT>flying_strength</TT> routine provided by the

761

<TT>kestrel</TT> (the same one it inherited from <TT>Bird</TT>), which adds its wingspan of

762

15 to the number of worms it has so far eaten (none), and then returns 15.

763

(You can see all the messages being sent in a game as it runs

764

with the debugging verb "messages'': see <A HREF="section30.html">Section 30</A> for details.)

765

766

767

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> For examples of all the other kinds of receiving property, here is

768

roughly what happens when the Inform library tries to move the player northeast

769

from the current room (the <TT>location</TT>) in an adventure game:

770

<PRE>

771

x = location.ne_to();

772

if (x == nothing) "You can't go that way.";

773

if (x ofclass Object) move player to x;

774

</PRE>

775

776

This allows directions to be given with some flexibility in properties like

777

<TT>ne_to</TT> and so on:

778

<PRE>

779

Object Octagonal_Room "Octagonal Room"

780

with ...

781

ne_to "The north-east doorway is barred by an invisible wall!",

782

w_to Courtyard,

783

e_to

784

[; if (Amulet has worn)

785

{ print "A section of the eastern wall suddenly parts before

786

you, allowing you into...^";

787

return HiddenShrine;

788

}

789

790

s_to

791

[; if (random(5) ~= 1) return Gateway;

792

print "The floor unexpectedly gives way, dropping you through

793

an open hole in the plaster...^";

794

return random(Maze1, Maze2, Maze3, Maze4);

795

];

796

</PRE>

797

798

799

800

801

Two special variables help with the writing of message routines:

802

<TT>self</TT> and <TT>sender</TT>. <TT>self</TT> always has as value the <TT>Object</TT> which is

803

receiving the message, while <TT>sender</TT> has as value the <TT>Object</TT> which sent it,

804

or <TT>nothing</TT> if it wasn't sent from <TT>Object</TT> (but from some free-standing

805

routine). For example,

806

<PRE>

807

pass_number

808

[; if (~~(sender ofclass CIA_Operative))

809

"Sorry, you aren't entitled to know that.";

810

return 16339;

811

];

812

</PRE>

813

814

815

<HR><BLOCKQUOTE><H3>3.10. Access to superclass values</H3></BLOCKQUOTE>

816

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> A fairly common situation in Inform coding is that one has a general

817

class of objects, say <TT>Treasure</TT>, and wants to create an instance of this class

818

which behaves slightly differently. For example, we might have

819

<PRE>

820

Class Treasure

821

with deposit

822

[; if (self provides deposit_points)

823

score = score + self.deposit_points;

824

else score = score + 5;

825

"You feel a sense of increased esteem and worth.";

826

];

827

</PRE>

828

829

and we want to create an instance called <TT>Bat_Idol</TT> which (say) flutters

830

away, resisting deposition, but only if the room is dark:

831

<PRE>

832

Treasure Bat_Idol "jewelled bat idol"

833

with deposit

834

[; if (location == thedark)

835

{ remove self;

836

"There is a clinking, fluttering sound!";

837

}

838

...

839

];

840

</PRE>

841

842

In place of <TT>...</TT>, we have to copy out all of the previous code about

843

depositing treasures. This is clumsy: what we really want is a way of

844

sending the deposit message to <TT>Bat_Idol</TT> but "as if it had not changed the

845

value of deposit it inherited from <TT>Treasure</TT>''. We achieve this with the

846

so-called superclass operator, <TT>::</TT>. (The term "superclass'' is borrowed

847

from the Smalltalk-80 system, where it is more narrowly defined.) Thus, in

848

place of <TT>...</TT>, we could simply write:

849

<PRE>

850

self.Treasure::deposit();

851

</PRE>

852

853

to send itself the <TT>deposit</TT> message again, but this time diverted to the

854

property as provided by Treasure.

855

856

857

858

859

The <TT>::</TT> operator works on all property values, not just for message sending.

860

In general,

861

<PRE>

862

object.class::property

863

</PRE>

864

865

evaluates to the value of the given property which the class would normally

866

pass on (or gives an error if the class doesn't provide that property or if

867

the object isn't a member of that class). Note that <TT>::</TT> exists as an operator

868

in its own right, so it is perfectly legal to write, for example,

869

<PRE>

870

x = Treasure::deposit; Bat_Idol.x();

871

</PRE>

872

873

To continue the avian theme, <TT>BirdOfPrey</TT> might have its

874

own <TT>flying_strength</TT> routine:

875

<PRE>

876

flying_strength

877

[; return self.Bird::flying_strength() + self.people_eaten;

878

879

</PRE>

880

881

reflecting the idea that, unlike other birds, these can gain strength by

882

eating people.

883

884

885

886

<HR><BLOCKQUOTE><H3>3.11. Philosophy</H3></BLOCKQUOTE>

887

888

<TR><TD Valign="top"><IMG SRC="icons/ddbend.gif" ALT="/\/\"><TD bgcolor="#EEEEEE"> This section is best skipped until the reader feels entirely happy

889

with the rest of Chapter I. It is aimed mainly at those worried

890

about whether the ideas behind the apparently complicated system of classes and

891

objects are sound. (As Stephen Fry once put it, "Socialism is all very well

892

in practice, but does it work in theory?'') We begin with two definitions:

893

894

895

896

<TR><TD><TD bgcolor="#EEEEEE"> -- object

897

-- a member of the program's object tree, or a routine in the

898

program, or a literal string in the program. (Routines and

899

strings can't, of course, be moved around in the object tree, but

900

the tests <TT>ofclass</TT> and <TT>provides</TT> can be applied to them, and

901

they can be sent messages.) Objects are part of the compiled

902

program produced by Inform.

903

-- class

904

-- an abstract name for a set of objects in the game, which may have

905

associated with it a set of characteristics shared by its objects.

906

Classes themselves are frequently described by text in the program's

907

source code, but are not part of the compiled program produced by Inform.

908

909

910

Here are the full rules:

911

(1) -- Compiled programs are composed of objects, which may have variables

912

attached called "properties''.

913

(2) -- Source code contains definitions of both objects and classes.

914

(3) -- Any given object in the program either is, or is not, a member of

915

any given class.

916

(4) -- For every object definition in the source code, an object is made

917

in the final program. The definition specifies which classes this object is

918

a member of.

919

(5) -- If an object <TT>X</TT> is a member of class <TT>C</TT>, then <TT>X</TT> "inherits''

920

property values as given in the class definition of <TT>C</TT>.

921

922

923

The details of how inheritance takes place are omitted here.

924

But note that one of the things which can be inherited from class <TT>C</TT> is being

925

a member of some other class, <TT>D</TT>.

926

927

(6) -- For every class definition, an object is made in the final program

928

to represent it, called its "class-object''.

929

For example, suppose we have a class definition like:

930

<PRE>

931

Class Dwarf

932

with beard_colour;

933

</PRE>

934

935

The class <TT>Dwarf</TT> will generate a class-object in the final program, also

936

called <TT>Dwarf</TT>. This class-object exists in order to receive messages like

937

<TT>create</TT> and <TT>destroy</TT> and, more philosophically, in order to represent

938

the concept of "dwarfness'' within the simulated world.

939

940

941

It is important to remember that the class-object of a class is not normally

942

a member of that class. The concept of dwarfness is not itself a dwarf:

943

the condition <TT>Dwarf ofclass Dwarf</TT> is false. Individual dwarves provide

944

a property called <TT>beard_colour</TT>, but the class-object of <TT>Dwarf</TT> does not:

945

the concept of dwarfness has no single beard colour.

946

947

(7) -- Classes which are automatically defined by Inform are called

948

"metaclasses''. There are four of these: <TT>Class</TT>, <TT>Object</TT>, <TT>Routine</TT>

949

and <TT>String</TT>.

950

951

It follows by rule (6) that every Inform program contains the class-objects

952

of these four, also called <TT>Class</TT>, <TT>Object</TT>, <TT>Routine</TT> and <TT>String</TT>.

953

954

(8) -- Every object is a member of one, and only one, metaclass:

955

(8.1) -- The class-objects are members of <TT>Class</TT>, and no other class.

956

(8.2) -- Routines in the program (including those given as property

957

values) are members of <TT>Routine</TT> and no other class.

958

(8.3) -- Static strings in the program (including those given as property

959

values) are members of <TT>String</TT>, and of no other class.

960

(8.4) -- The objects defined in the source code are members of <TT>Object</TT>,

961

and possibly also of other classes defined in the source code.

962

963

It follows from (8.1) that <TT>Class</TT> is the unique class whose class-object

964

is one of its own members: the condition <TT>Class ofclass Class</TT> is true,

965

whereas <TT>X ofclass X</TT> is false for every other class <TT>X</TT>.

966

967

968

There is one other unusual feature of metaclasses, and it is a rule provided

969

for pragmatic reasons (see below) even though it is not very elegant:

970

971

(9) -- Contrary to rules (5) and (8.1), the class-objects of the four

972

metaclasses do not inherit from <TT>Class</TT>.

973

974

975

976

This concludes the list of rules. To see what they entail, one needs to

977

know the definitions of the four metaclasses. These definitions are never

978

written out in any textual form inside Inform, as it happens, but here are

979

definitions equivalent to what actually does happen. (There is no such

980

directive as <TT>Metaclass</TT>: none is needed, since only Inform itself can

981

define metaclasses, but the definitions here pretend that there is.)

982

<PRE>

983

Metaclass Object;

984

</PRE>

985

986

In other words, this is a class from which nothing is inherited. So the

987

ordinary objects described in the source code only have the properties which

988

the source code says they have.

989

<PRE>

990

Metaclass Class

991

with create [; ... ],

992

recreate [ instance; ... ],

993

destroy [ instance; ... ],

994

copy [ instance1 instance2; ... ],

995

remaining [; ... ];

996

</PRE>

997

998

So class-objects respond only to these five messages, which are described in

999

detail in the next section, and provide no other properties: except that

1000

by rule (9), the class-objects <TT>Class</TT>, <TT>Object</TT>, <TT>Routine</TT> and <TT>String</TT>

1001

provide no properties at all. The point is that these five messages are

1002

concerned with object creation and deletion at run time. But Inform is a

1003

compiler and not, like Smalltalk-80 or other highly object-oriented

1004

languages, an interpreter. We cannot create the program while it is actually

1005

running, and this is what it would mean to send requests for creation or

1006

deletion to <TT>Class</TT>, <TT>Object</TT>, <TT>Routine</TT> or <TT>String</TT>. (We could write the

1007

above routines to allow the requests to be made, but to print out some error

1008

if they ever are: but it is more efficient to have rule (9) instead.)

1009

<PRE>

1010

Metaclass Routine

1011

with call [ parameters...; ... ];

1012

</PRE>

1013

1014

Routines therefore provide only <TT>call</TT>. See the next section for how to use

1015

this.

1016

<PRE>

1017

Metaclass String

1018

with print [; print_ret (string) self; ],

1019

print_to_array [ array; ... ];

1020

</PRE>

1021

1022

Strings therefore provide only <TT>print</TT> and <TT>print_to_array</TT>. See the next

1023

section for how to use these.

1024

1025

1026

To demonstrate this, here is an Inform code representation of what happens

1027

when the message

1028

<PRE>

1029

O.M(p1, p2, ...)

1030

</PRE>

1031

1032

is sent.

1033

<PRE>

1034

if (~~(O provides M)) "Error: O doesn't provide M";

1035

P = O.M;

1036

switch(metaclass(P))

1037

{ nothing, Object, Class: return P;

1038

Routine: return P.call(p1, p2, ...);

1039

String: return P.print();

1040

}

1041

</PRE>

1042

1043

(The messages <TT>call</TT> and <TT>print</TT> are actually implemented by hand, so this

1044

is not actually a circular definition. Also, this is simplified to remove

1045

details of what happens if <TT>P</TT> is an array.)

1046

1047

1048

1049

<HR><BLOCKQUOTE><H3>3.12. Sending messages to routines, strings or classes</H3></BLOCKQUOTE>

1050

1051

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> In the examples so far, messages have only been sent to proper

1052

<TT>Object</TT>s. But it's a logical possibility to send messages to objects of the

1053

other three metaclasses too: the question is whether they are able to receive

1054

any. The answer is yes, because Inform provides 8 properties for such objects,

1055

as follows.

1056

1057

1058

1059

1060

The only thing you can do with a <TT>Routine</TT> is to call it. Thus, if <TT>Explore</TT> is

1061

the name of a routine, then

1062

<PRE>

1063

Explore.call(2, 4); and Explore(2, 4);

1064

</PRE>

1065

1066

are equivalent expressions. The message <TT>call(2,4)</TT> means "run this routine

1067

with parameters (2,4)''. This is not quite redundant, because it can be used

1068

more flexibly than ordinary function calls:

1069

<PRE>

1070

x = Explore; x.call(2, 4);

1071

</PRE>

1072

1073

The <TT>call</TT> message replies with the routine's return value.

1074

1075

1076

Two different messages can be sent to a <TT>String</TT>. The first is <TT>print</TT>, which

1077

is provided because it logically ought to be, rather than because it is

1078

useful. So, for example,

1079

<PRE>

1080

("You can see an advancing tide of bison!").print();

1081

</PRE>

1082

1083

prints out the string, followed by a new-line; the <TT>print</TT> message replies

1084

<TT>true</TT>, or 1.

1085

1086

1087

<TR><TD Valign="top"><IMG SRC="icons/ddbend.gif" ALT="/\/\"><TD bgcolor="#EEEEEE"> <TT>print_to_array</TT> is more useful. It copies out the text of the

1088

string into entries 2, 3, 4, ... of the supplied byte array, and writes the

1089

number of characters as a word into entries 0 and 1. That is, if <TT>A</TT> has

1090

been declared as a suitably large array,

1091

<PRE>

1092

("A rose is a rose is a rose").print_to_array(A);

1093

</PRE>

1094

1095

will cause the text of the string to be copied into the entries

1096

<PRE>

1097

A->2, A->3, ..., A->27

1098

</PRE>

1099

1100

with the value 26 written into

1101

<PRE>

1102

A-->0

1103

</PRE>

1104

1105

And the reply value of the message is also 26, for convenience.

1106

1107

1108

1109

1110

Five different messages can be sent to objects of metaclass Class, i.e., to

1111

classes, and these are detailed in the next section. (But an exception to this

1112

is that no messages at all can be sent to the four metaclasses <TT>Class</TT>,

1113

<TT>Object</TT>, <TT>Routine</TT> and <TT>String</TT>.)

1114

1115

1116

1117

<HR><BLOCKQUOTE><H3>3.13. Creating and deleting objects</H3></BLOCKQUOTE>

1118

1119

1120

A vexed problem in all object-oriented systems is that it is often elegant

1121

to grow data structures organically, simply conjuring new objects out of

1122

mid-air and attaching them to the structure already built. The problem

1123

is that since resources cannot be infinite, there will come a point

1124

where no new objects can be conjured up. The program must be written so

1125

that it can cope with this, and this can present the programmer with

1126

some difficulty, since the conditions that will prevail when the program

1127

is being run may be hard to predict.

1128

1129

1130

In an adventure-game setting, object creation is useful for something like

1131

a beach full of stones: if the player wants to pick up more and more stones,

1132

the game needs to create a new object for each stone brought into play.

1133

1134

1135

Inform allows object creation, but it insists that the programmer must specify

1136

in advance what the maximum resources ever needed will be: for example, the

1137

maximum number of stones which can ever be in play. Although this is

1138

a nuisance, the reward is that the resulting program is guaranteed to work

1139

correctly on every machine running it (or else to fail in the same way

1140

on every machine running it).

1141

1142

1143

The model is this. When a class is defined, a number N is specified, which

1144

is the maximum number of created instances of the class which the programmer

1145

will ever need at once. When the program is running, "instances'' can be

1146

created (up to this limit); or deleted. One can imagine the class having a

1147

stock of instances, so that creation consists of giving out one of the

1148

stock-pile and deletion consists of taking one back.

1149

1150

1151

Classes can receive the following five messages:

1152

1153

1154

<TT>remaining()</TT>

1155

What is the current value of N? That is, how many

1156

more instances can be created?

1157

<TT>create()</TT>

1158

Replies with a newly created instance, or

1159

with <TT>nothing</TT> if no more can be created.

1160

<TT>destroy(I)</TT>

1161

Destroys the instance <TT>I</TT>, which must previously have

1162

been created.

1163

<TT>recreate(I)</TT>

1164

Re-initialises the instance <TT>I</TT>, as if it had been

1165

destroyed and then created again.

1166

1167

Copies <TT>I</TT> to be equal to <TT>J</TT>, where both have to be

1168

instances of the class.

1169

1170

1171

1172

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> Note that <TT>recreate</TT> and <TT>copy</TT> can be sent for any instances, not just

1173

instances which have previously been created. For example,

1174

<PRE>

1175

Plant.copy(Gilded_Branch, Poison_Ivy)

1176

</PRE>

1177

1178

copies over all the <TT>Plant</TT> properties and attributes from <TT>Poison_Ivy</TT> to

1179

<TT>Gilded_Branch</TT>, but leaves all the rest alone. Likewise,

1180

<PRE>

1181

Treasure.recreate(Gilded_Branch)

1182

</PRE>

1183

1184

only resets the properties to do with <TT>Treasure</TT>, leaving the <TT>Plant</TT> properties

1185

alone.

1186

1187

1188

1189

Unless the definition of a class <TT>C</TT> is made in a special way, <TT>C.remaining()</TT>

1190

will always reply 0, <TT>C.destroy()</TT> will cause an error and <TT>C.create()</TT> will

1191

be refused. This is because the magic number N for a class is normally 0.

1192

1193

1194

The "special way'' is to give N in brackets after the class name. For

1195

example, if the class definition for <TT>Leaf</TT> begins:

1196

<PRE>

1197

Class Leaf(100) ...

1198

</PRE>

1199

1200

then initially <TT>Leaf.remaining()</TT> will reply 100, and the first 100 <TT>create()</TT>

1201

messages will certainly be successful. Others will only succeed if leaves

1202

have been destroyed in the mean time. In all other respects <TT>Leaf</TT> is an

1203

ordinary class.

1204

1205

1206

<TR><TD Valign="top"><IMG SRC="icons/dbend.gif" ALT="/\"><TD bgcolor="#EEEEEE"> Object creation and destruction may need to be more sophisticated

1207

than this. For example, we might have a data structure in which every object

1208

of class <TT>A</TT> is connected in some way with four objects of class <TT>B</TT>. When a

1209

new <TT>A</TT> is created, four new <TT>B</TT>s need to be created for it; and when an <TT>A</TT> is

1210

destroyed, its four <TT>B</TT>s need to be destroyed. In an adventure game setting,

1211

we might imagine that every Dwarf who is created has to carry an Axe of his own.

1212

1213

1214

1215

1216

When an object has been created (or recreated), but before it has been

1217

"given out'' to the program, a <TT>create</TT> message is sent to it (if it provides

1218

<TT>create</TT>). This gives the object a chance to set itself up sensibly.

1219

Similarly, when an object is about to be destroyed, but before it actually is, a

1220

<TT>destroy</TT> message is sent to it (if it provides <TT>destroy</TT>). For example:

1221

<PRE>

1222

Class Axe(30);

1223

Class Dwarf(7)

1224

with beard_colour,

1225

create

1226

[ x; self.beard_colour = random("black", "red", "white", "grey");

1227

1228

! Give this new dwarf an axe, if there are any to spare

1229

1230

x = Axe.create(); if (x ~= nothing) move x to self;

1231

1232

destroy

1233

[ x;

1234

! Destroy any axes being carried by this dwarf

1235

1236

objectloop (x in self && x ofclass Axe) Axe.destroy(x);

1237

];

1238

</PRE>

1239

1240

1241

1242

1243

<HR><BLOCKQUOTE><H3>3.14. Footnote on common vs. individual properties</H3></BLOCKQUOTE>

1244

1245

1246

1247

The properties used in the sections above are all examples of

1248

"individual properties'', which some objects provide and others do not.

1249

There are also "common properties'' which, because they are inherited

1250

from the class <TT>Object</TT>, are held by every member of <TT>Object</TT>.

1251

An example is <TT>capacity</TT>. The <TT>capacity</TT> can be read for an ordinary

1252

game object (say, a crate) even if it doesn't specify a

1253

<TT>capacity</TT> for itself, and the resulting "default'' value will

1254

be 100. However, this is only a very weak form of inheritance --

1255

you can't change the crate's <TT>capacity</TT> value and the condition

1256

<TT>crate provides capacity</TT> evaluates to <TT>false</TT>.

1257

1258

1259

The properties defined by the Inform library, such as

1260

<TT>capacity</TT>, are all common: mainly because common properties

1261

are marginally faster to access and marginally cheaper on memory.

1262

Only 62 are available, of which the library uses up 48.

1263

Individual properties, on the other hand, are practically

1264

unlimited. It is therefore worth declaring a common property only

1265

in those cases where it will be used very often in your program.

1266

You can declare common properties with the directive:

1267

1268

<TT>Property </TT><name><TT>;</TT>

1269

</BLOCKQUOTE>

1270

1271

which should be made after the inclusion of "Parser'' but before

1272

first use of the new name. The class <TT>Object</TT> will now

1273

pass on this property, with value 0, to all its members. This

1274

so-called "default value'' can optionally be specified. For

1275

example, the library itself makes the declaration

1276

1277

<TT>Property capacity 100;</TT>

1278

</BLOCKQUOTE>

1279

1280

which is why all containers in a game which don't specify any particular

1281

<TT>capacity</TT> can hold up to 100 items.

1282

1283

</TABLE>

1284

<HR><A HREF="contents.html">Contents</A> / <A HREF="section2.html">Back</A> / <A HREF="chapter2.html">Forward</A>

1285

<A HREF="chapter1.html">Chapter I</A> / <A HREF="chapter2.html">Chapter II</A> / <A HREF="chapter3.html">Chapter III</A> / <A HREF="chapter4.html">Chapter IV</A> / <A HREF="chapter5.html">Chapter V</A> / <A HREF="chapter6.html">Chapter VI</A> / <A HREF="chapterA.html">Appendix</A><HR>Mechanically translated to HTML from third edition as revised 16 May 1997. Copyright © Graham Nelson 1993, 1994, 1995, 1996, 1997: all rights reserved.</BODY></HTML>

Older »