Footnotes

(1)

The file is called `_stpre' under MS-DOS and `.gstpre' on the Atari ST. Under OSes that don't use home directories it is looked for in the current directory.

The same considerations made above hold here too. The file is called `_stinit' under MS-DOS and `.gstinit' on the Atari ST, and is looked for in the current directory under OSes that don't use home directories.

(3)

An inheritance tree in the current GNU Smalltalk implementation of namespaces; a class can fake multiple inheritance by specifying a namespace (environment, if you prefer) as one of its pool dictionaries.

(4)

Absent from the original paper.

(5)

When using an alternate image path, don't use the -K option and pass the full path to the `Load.st' script.

(6)

The ? method does not apply to the LcMessagesDomain class itself, but only to its instances. This is because LcMessagesDomain is not a subclass of Locale.

(7)

Extreme Programming is a software engineering technique that focuses on team work (to the point that a programmer looks in real-time at what another one is typing), frequent testing of the program, and incremental design.

(8)

A Wiki is a kind of collaborative web site, which allows one to edit the contents of a page.

(9)

The most notable are AIX and Windows.

(10)

Specifying -no-undefined is not necessary, but it does perform that the portability conditions explained above (no reference to symbols in the virtual machine) are satisfied

(11)

Actually they have a common superclass named CCompound.

(12)

The old #newStruct:declaration: method for creating CStructs is deprecated because it does not allow one to set the category.

(13)

It also prints out a lot of statistics. Ignore these; they provide information on the performance of the underlying Smalltalk engine. You can inhibit them by starting Smalltalk as either:

$ gst -q
or

$ gst -r

(14)

Which table? This is determined by the type of the object. An object has a type, known as the class to which it belongs. Each class has a table of methods. For the object we created, it is known as a member of the String class. So we go to the table associated with the String class.

(15)

Actually, the message printNl was inherited from Object. It sent a print message, also inherited by Object, which then sent printOn: to the object, specifying that it print to the Transcript object. The String class then prints its characters to the standard output.

(16)

GNU Smalltalk supports completion in the same way as Bash or GDB. To enter the following line, you can for example type `x := Arr<TAB> new: 20'. This can come in handy when you have to type long names such as IdentityDictionary, which becomes `Ide<TAB>D<TAB>'. Everything starting with a capital letter or ending with a colon can be completed.

(17)

Alert readers will remember that the math examples of the previous chapter deviated from this.

(18)

Actually, a SystemDictionary, which is just a Dictionary with some extra methods to run things when Smalltalk first starts and to do nice things with a Smalltalk environment

(19)

For more detail, See section 5.11.2 Two flavors of equality

(20)

In case you're having a hard time making out the font, the " after classVariableNames: and poolDictionaries: are a pair of single quotes--an empty string.

(21)

And unlike C, Smalltalk draws a distinction between 0 and nil. nil is the nothing object, and you will receive an error if you try to do, say, math on it. It really does matter that we initialize our instance variable to the number 0 if we wish to do math on it in the future.

(22)

And why didn't the designers default the return value to nil? Perhaps they didn't appreciate the value of void functions. After all, at the time Smalltalk was being designed, C didn't even have a void data type.

(23)

self is much like super, except that self will start looking for a method at the bottom of the type hierarchy for the object, while super starts looking one level up from the current level. Thus, using super forces inheritance, but self will find the first definition of the message which it can.

(24)

Of course, in a real accounting system we would never discard such information--we'd probably throw it into a Dictionary object, indexed by the year that we're finishing. The ambitious might want to try their hand at implementing such an enhancement.

(25)

It is interesting to note that because of the way conditionals are done, conditional constructs are not part of the Smalltalk language, instead they are merely a defined behavior for the Boolean class of objects.

(26)

You might start to wonder what one would do if you wished to associate two pieces of information under one key. Say, the value and who the check was written to. There are several ways; the best would probably be to create a new, custom object which contained this information, and then store this object under the check number key in the dictionary. It would also be valid (though probably over-kill) to store a dictionary as the value--and then store as many pieces of information as you'd like under each slot!

(27)

The do: message is understood by most types of Smalltalk collections. It works for the Dictionary class, as well as sets, arrays, strings, intervals, linked lists, bags, and streams. The associationsDo: message works only with dictionaries. The difference is that do: passes only the value portion, while associationsDo: passes the entire key/value pair in an Association object.

(28)

There is also a valueWithArguments: message which accepts an array holding as many arguments as you would like.

(29)

When using the Blox GUI, it actually pops up a so-called Inspector window.

(30)

This listing is courtesy of the printHierarchy method supplied by GNU Smalltalk author Steve Byrne. It's in the `kernel/Browser.st' file.

(31)

Smalltalk also offers an or: message, which is different in a subtle way from |. or: takes a code block, and only invokes the code block if it's necessary to determine the value of the expression. This is analogous to the guaranteed C semantic that || evaluates left-to-right only as far as needed. We could have written the expressions as ((index < 1) or: [index > (self basicSize)]). Since we expect both sides of or: to be false most of the time, there isn't much reason to delay evaluation of either side in this case.