Having stopped off to consider the most important class of all—Object—in more detail, we can now continue our tour of the Smalltalk class library where we left off.
Kernel-Objects
Besides object, this category also contains some other very commonly used classes which are essential to the functioning of the system. In particular, the classes Boolean, True and False implement all of the functionality to do with logical operations in Smalltalk. The class Boolean defines all the operations, but they are actually implemented in its subclasses—True and False. Each of these subclasses has a single instance called t r u e and f a l s e respectively. Browsing Boolean will show you all the kinds of logical operations (&, |, not, etc.) which Smalltalk supports, and the kinds of control structure (ifFalse: , ifTrue;, etc.) you can use.
Notice how once again, things you might have thought would be part of the language (like arithmetic) are actually a part of the class library. For example, a conditional statement is implemented by sending the message if True: to an object with a block as the parameter. The block is executed only if the object was an instance of class True, and not if it was an instance of class False. For example:
27 > (3+4) ifTrue: [Transcript show: 'Bigger!'].
Browse the implementation of ifTrue: in the classes True and False to see how this works. Do note though, that although this particular functionality is expressed as a set of methods, the compiler can actually spot these messages being sent and compile them 'in-line', optimising their execution. This means that changing the definitions of ifTrue: or ifFalse: (dangerous as that might otherwise be) won't actually have the effect you might intend. It also means that the debugger will sometimes get confused about where exactly any errors in the use of these messages are located in your source-code.
Look carefully at the difference between & and and: (also | and or: ) in the boolean classes. The first pair of methods (& and | ) take an expression as their argument, and are guaranteed to execute that expression. The second pair of methods (and ; and or:) take a block as their argument, and will only execute that block if its value is needed to resolve the logical value of the whole expression. This means that if the expression or block used as an argument has a side-effect as well as returning a value, the choice of & or and: (| or or:) is critical. For example, in the first of the following two expressions fred will be set to true. In the second it won't because there's no need to evaluate the block to know that the whole expression is true.
(1=1) | (fred := true).
(1=1) or: [fred := true].
The Smalltalk Class Library
Another important class in this category is UndefinedObject. The system contains only a single instance of this class, called nil. Many of the methods UndefinedObj eot implements are to do with undoing the functionality inherited from Object! The value nil is used to represent the notion of 'nothing' or 'undefined'. It is also the value to which all newly declared variables are initialised.
Finally in the Kernel-Objects category, the class Model is simply a subclass of object which implements dependency (see chapter 8 again) differently for efficiency reasons.
Kernel-Classes
This category contains all the classes which implement the very notion of a 'class' in Smalltalk. This really is the internals of the system, and can be very confusing. However it is useful to know that just as all objects can understand the messages defined in the class Object, all classes can understand the messages defined in the classes Behavior, ClassDescripfcion and Class (which inherit from each other in that order). This is because class objects are instances of the class Class (think about it, but don't worry if you find it confusing).
There is some very useful functionality in Behavior, especially for accessing the subclasses and superclasses of a class, and finding all its instances (alllnstances). The latter message can be very useful during debugging, but remember you can only send it to a class.
Perhaps the most important single message defined in the Kernel-Classes category is new. This is the message you can send 1 to any class to ask it to make and return a new instance of itself. You i might think that this should be defined on the class side of Object, but ) in fact because of the complexities of the Smalltalk class system (which we shall not be going into here), it is defined on the instance side of Behavior. This still means that any and every class understands the message new, although many provide more appropriate instance creation methods too. Note though that some classes which are intended never to have instances (abstract superclasses) explicitly 'un-implement' the new method. They do this by over-riding it with the expression self shouldNot Implement.
The rest of the Kernel categories deal with internal things which again are probably not of much immediate interest. The only exceptions are the class Process, which implements and provides access to Smalltalk's own lightweight process mechanism (look in the manual for more details), and the class BlockClosure, which implements the block notion we looked at in the previous chapter.
BlockClosure also provides some more of the Smalltalk control structures which are sprinkled around the class hierarchy. In particular there are the methods repeat, whileFalse, whileTrue, and their variants. You can browse their implementations to see how they work but here is an example:
EMyWindow isTooBig] whileFalse: EMyWindow grow],
Interface-Framework
This and the remainder of the Interface- categories contain all the classes which implement the Smalltalk user-interface. These categories, together with all the uiBasics and UlLooks categories, contain hundreds of different classes for implementing widgets, windows and everything in between. Thankfully, because of the existence of the VisualWorks GUI building tools (implemented by classes in the UZPainter and ulBuilder categories) you will rarely need to access all these classes explicitly. Remember though that if you need to do so, (and if you want to build user-interfaces which VisualWorks doesn't support, you will) the source-code is here for you to browse, understand and use. A few of these classes are important enough, and illustrate such useful general principles, that we will be describing them in more detail in Chapter 10—Pluggability andAdaptors.
Tools- Programming
This and the rest of the Tools- categories contain the classes which implement the browsers, inspectors, debuggers and so on that we looked at in chapter 5. If you don't like the way any of these tools behave, this is the place to go to find out how they work, and modify them.
Sys t em-Change s
This and the other System - categories contain the classes used by the Smalltalk compiler. Unless you really want to modify the internals of the system, you should never have any need to go near these classes.
OS-Window System
This category contains classes used to interface Smalltalk to the underlying window system. This is the place to go if you are interested
The Smalltalk Class Library
in gaining access to that mechanism for any reason. However, for normal GUI programming you should have no need to deal with any of these classes. The only exception is perhaps the class Cursor. This class provides methods you can use if you want to change the shape of the mouse cursor.
OS-Streaming
The classes in here provide support for accessing files in the underlying operating system. Sometimes you may want to create instances of these classes directly, but more usually you would use an instance of the class Filename to create one for you.
OS-Support
This category contains the class Filename, which is your easiest and most portable route to opening a file in the underlying filesystem.
OS-Unix, OS-Dos, OS-Mac
These categories contain classes whichspecialise the abstract notions of filename and other things which Smalltalk deals with, to the particular platform which the virtual machine is actually running on.
They enable some of the cross-platform portability which VisualWorks provides.
External-Collections
This and the other External- categories contain classes which represent entities to do with connecting Smalltalk up to other languages such as C or C++. How you do this depends to a large extent on exactly what sort of machine you have, so you'll need to look in the manual for details.
UIExamples
Finally in this tour of the class library, the various ulExamples categories contain the many classes used to implement the example applications provided as part of the VisualWorks system. This is a good place to start if you want to try modifying some of these examples applications, or need to find out how they implement a particular piece of behaviour.
We've now completed our introduction to the Smalltalk class library. If you've followed the tour, you should find that you're familiar (both from the descriptions given here, and from just browsing around) with some of the standard protocols which exist in many of the system classes. You should also have an idea how to predict from the name of a protocol the kinds of method it will contain.
You should now know something about the messages all objects understand (defined in class Object), and the messages all classes understand (defined in Behavior, ClassDescription and Class).
You should know where to find arithmetic operations defined (ArithmeticValue and its subclasses) and where to find logical operations and control structures (Boolean and its subclasses). Finally, you should have a good idea of what kinds of functionality the rest of the class library contains.
The remainder of this part of the book is concerned with more detailed descriptions of some of the features and classes we've mentioned here. The classes have been chosen not only because they are useful to know about, but also because they illustrate some of the style of good Smalltalk programming. Part 11 of the book then goes on to explain how you can learn even more about the Smalltalk system for yourself, and more importantly how you can design your own classes to fit in with it.