- Chapter 14 Kernel Support
Object Magnitude Character Date Time Number Float Fraction Integer LargeNegativeInteger LargePositiveInteger SmallInteger LookupKey Association Link Process Collection SequenceableCollection LinkedList Semaphore ArrayedCollection Array Bitmap DisplayBitmap RunArray String Symbol Text ByteArray Interval OrderedCollection SortedCollection Bag MappedCollection Set Dictionary IdentifyDictionary Stream PositionableStream ReadStream WriteStream ReadWriteStream ExternalStream FileStream Random File FileDirectory FilePage UndefinedObject*** Boolean*** False*** True*** ProcessorScheduler Delay SharedQueue Behavior ClassDescription Class MetaClass Point Rectangle BitBit CharacterScanner Pen DisplayObject DisplayMedium Form Cursor DisplayScreen InfiniteForm OpaqueForm Path Arc Circle Curve Line LinearFit Spline
The object nil represents a value for uninitialized variables. It also represents meaningless results. It is the only instance of class UndefinedObject.
The purpose of including class UndefinedObject in the system is to handle error messages.The typical error in evaluating Smal]talk-80 expressions is that some object is sent a message it does not understand. Often this occurs because a variable is not properly initialized--in many cases, the variable name that should refer to some other object refers to nil instead. The error message is of the form
className does not understand messageSelector
where className mentions the class of the receiver and messageSelector is the selector of the erroneously-sent message.
Note, if nil were an instance of Object, then a message sent to it in error would state
Object does not understand messageSelector
which is less explicit than stating that an undefined object does not understand the message. At the price of a class description, it was possible to improve on the error message.
Tests to see if an object is nil are handled in class Object, but reimplemented in UndefinedObject. In class Object, messages isNil and notNil are implemented as
isNil ↑false notNil ↑true
In class UndefinedObject, messages isNil and notNil are implemented as
isNil ↑true notNil ↑false
so that no conditional test in Object is required.
Classes Boolean, True, and False
Protocol for logical values is provided by the class Boolean; logical values are represented by subclasses of Boolean~True and False. The subclasses add no new protocol; they reimplement many messages to have better performance than the methods in the superclass. The idea is similar to that in testing for nil in Object and UndefinedObject; true knows that it represents logical truth and false knows that it represents logical falsehood. We show the implementation of some of the controlling protocol to illustrate this idea.
The logical operations are
|& aBoolean||Evaluating conjunction. Answer true if both the receiver and the argument are true.|
|| aBoolean||Evaluating disjunction. Answer true if either the receiver or the argument is true.|
|not||Negation. Answer true if the receiver is false, answer false if the receiver is true.|
|eqv: aBoolean||Answer true if the receiver is equivalent to the argument, aBoolean.|
|xor: aBoolean||Exclusive OR. Answer true if the receiver is not equivalent to aBoolean.|
|Boolean instance protocol|
These conjunction and disjunction operations are "evaluating" --this means that the argument is evaluated regardless of the value of the receiver. This is in contrast to and: and or: in which the receiver determines whether to evaluate the argument.
|and: alternativeBlock||Nonevaluating conjunction. If the receiver is true, answer the value of the argument; otherwise, answer false without evaluating the argument.|
|or: alternativeBlock||Nonevaluating disjunction. If the receiver is false, answer the value of the argument; otherwise, answer true without evaluating the argument.|
|ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock||Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBlock; otherwise answer the result of evaluating falseAlternativeBlock.|
|ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock||Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBlock; otherwise answer the result of evaluating falseAlternativeBlock.|
|ifTrue: trueAlternativeBlock||Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBlock; otherwise answer nil.|
|ifFalse: falseAlternativeBlock||Conditional statement. If the receiver is false, answer the result of evaluating falseAlternativeBlock; otherwise answer nil.|
|Boolean instance protocol|
The arguments to and: and or: must be blocks in order to defer evaluation. Conditional statements are provided as messages ifTrue:ifFalse:, ifFalse:ifTrue:, ifTrue:, and ifFalse:, as already specified and exemplified throughout the previous chapters. The messages are implemented in the subclasses of class Boolean so that the appropriate argument block is evaluated.
In class True, the methods are
ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock ↑trueAlternativeBlock value ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock ↑trueAlternativeBlock value ifTrue: trueAlternativeBlock ↑trueAlternativeBlock value ifFalse: falseAlternativeBlock ↑nil
In class False, the methods are
ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock ↑falseAlternativeBlock value ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock ↑falseAlternativeBlock value ifTrue: trueAlternativeBlock ↑nil ifFalse: falseAlternativeBlock ↑falseAlternativeBlock value
If x is 3, then
x > 0 ifTrue: [x ← X - 1] ifFalse: [x ← x + 1]
is interpreted as x > 0 evaluates to true, the sole instance of class True; the method for ifTrue:ifFalse: is found in class True, so the block [x ← x - 1] is evaluated without further testing.
In this way, the message lookup mechanism provides an effective implementation of conditional control with no additional primitive operations or circular definitions.
Additional Protocol for Class Object
Protocol for class Object, shared by all objects, was introduced in Chapter 6. Several categories of messages were not included in that early discussion. Most of these are part of Object's protocol to provide system support for message handling, dependence relationships, primitive message handling, and system primitives.
Dependence Relationships Among Objects
Information in the Smalltalk-80 system is represented by objects. The variables of objects themselves refer to objects; in this sense, objects are explicitly related or dependent on one another. Classes are related to their superclasses and metaclasses; these classes share external and internal descriptions and are thereby dependent on one another. These forms of dependency are central to the semantics of the Smalltalk-80 language. They coordinate descriptive information among objects.
An additional kind of dependency is supported in class Object. Its purpose is to coordinateactivities among different objects. Specifically, its purpose is to be able to link one object, say A, to one or more other objects, say B, so B can be informed if A changes in any way. Upon being informed when A changes and the nature of the change, B can decide to take some action such as updating its own status. The concept of changeand update,therefore, are integral to the support of this third kind of object dependence relationship.
The protocol in class Object is
|addDependent: anObject||Add the argument, anObject, as one of the receiver's dependents.|
|removeDependent: anObject||Remove the argument, anObject, as one of the receiver's dependents.|
|dependents||Answer an OrderedCollection of the objects that are dependent on the receiver, that is, the objects that should be notified if the receiver changes.|
|release||Remove references to objects that may refer back to the receiver. This message is reimplemented by any subclass that creates references to dependents; the expression super release is included in any such reimplementation.|
|change and update|
|changed||The receiver changed in some general way; inform all the dependents by sending each dependent an update: message.|
|changed: aParameter||The receiver changed; the change is denoted by the argument, aParameter. Usually the argument is a Symbol that is part of the dependent's change protocol; the default behavior is to use the receiver itself as the argument. Inform all of the dependents.|
|update: aParameter||An object on whom the receiver is dependent has changed. The receiver updates its status accordingly (the default behavior is to do nothing).|
|broadcast: aSymbol||Send the argument, aSymbol, as a unary message to all of the receiver's dependents.|
|broadcast: aSymbol with: anObject||Send the argument, aSymbol, as a keyword message with argument, anObject, to all of the receiver's dependents.|
|Object instance protocol|
Take, as an example, the objects that model traffic lights. A typical traffic light at a street corner is an object with three lights, each a different color. Only one of these lights can be ON at a given moment. In this sense, the ON-OFF status of each of the three lights is dependent on the status of the other two. There are a number of ways to create this relationship. Suppose we create the class Light as follows.
|instance variable names||status|
instance creation setOn ↑self new setOn setOff ↑self new setOff
status turnOn self isOff ifTrue: [status ← true. self changed] turnOff self isOn ifTrue: [status ← false] testing isOn ↑status isOff ↑status not change and update update: aLight aLight = = self ifFalse: [self turnOff] private setOn status ← true setOff status ← false
The model is very simple. A Light is either on or off, so a status flag is kept as an instance variable; it is true if the Light is on, false if the Light is off. Whenever a Light is turned on (turnOn), it sends itself the changed message. Any other status change is not broadcast to the dependents on the assumption that a Light is turned off in reaction to turning on another Light. The default response to changed is to send all dependents the message update: self (i.e., the object that changed is the argument to the update: message). Then update: is implemented in Light to mean turn off. If the parameter is the receiver, then, of course, the update: is ignored.
The class TrafficLight is defined to set up any number of coordinated lights. The instance creation message with: takes as its argument the number of Lights to be created. Each Light is dependent on all other Lights. When the TrafficLight is demolished, the dependencies among its Lights are disconnected (the message inherited from class Object for disconnecting dependents is release; it is implemented in TrafficLight in order to broadcast the message to all Lights).
|instance variable names||lights|
instance creation with: numberOfLights ↑self new lights: numberOfLights
operate turnOn: lightNumber (lights at: lightNumber) turnOn initialize-release release super release. lights do: [ :eachLight | eachLight release]. lights ← nil private lights: numberOfLights lights ← Array new: (numberOfLights max: 1). lights at: 1 put: Light setOn. 2 to: numberOfLights do: [ :index | lights at: index put: Light setOff]. lights do: [ :eachLight | lights do: [ :dependentLight | eachLight ~~ dependentLight ifTrue: [eachLight addDependent: dependentLight]]]
The private initialization method is lights: numberOfLights. Each light is created turned off except for the first light. Then each light is connected to all the other lights (using the message addDependent:). The simulated TrafficLight operates by some round robin, perhaps timed, sequencing through each light, turning it on. A simple example shown below creates the TrafficLight with the first light on, and then turns on each of the other lights, one at a time. A simulation of a traffic corner might include different models for controlling the lights.
trafficLight ← TrafficLight with: 3. trafficLight turnOn: 2. trafficLight turnOn: 3
The message turnOn: to a TrafficLight sends the message turnOn to the designated Light. If the Light is currently off, then it is set on and the message changed sent. The message changed sends update: to each dependent Light; if a dependent light is on, it is turned off.
A particularly important use of this dependency protocol is to support having multiple graphical images of an object. Each image is dependent on the object in the sense that, if the object changes, the image must be informed so that it can decide whether the change affects the displayed information. The user interface to the Smalltalk-80 system makes liberal use of this support for broadcasting notices that an object has changed; this is used to coordinate the contents of a sequence of menus of possible actions that the user can take with respect to the contents of information displayed on the screen. Menus themselves can be created by linking possible actions together, in a way similar to the way we linked together the traffic lights.
All processing in the Smalltalk-80 system is carried out by sending messages to objects. For reasons of efficiency, instances of class Message are only created when an error occurs and the message state must be stored in an accessible structure. Most messages in the system, therefore, do not take the form of directly creating an instance of Message and transmitting it to an object.
In some circumstances, it is useful to compute the message selector of a message transmission. For example, suppose that a list of possible message selectors is kept by an object and, based on a computation, one of these selectors is chosen. Suppose it is assigned as a value of a variable selector. Now we wish to transmit the message to some object, say, to receiver. We can not simply write the expression as
because this means--send the object referred to by receiver the unary message selector. We could, however, write
receiver perform: selector
The result is to transmit the value of the argument, selector, as the message to receiver. Protocol to support this ability to send a computed message to an object is provided in class Object. This protocol includes methods for transmitting computed keyword as well as unary messages.
|perform: aSymbol||Send the receiver the unary message indicated by the argument, aSymbol.The argument is the selector of the message. Report an error if the number of arguments expected by the selector is not zero.|
|perform:aSymbol with: anObject||Send the receiver the keyword message indicated by the arguments. The first argument, aSymbol, is the selector of the message. The other argument, anObject, is the argument of the message to be sent. Report an error if the number of arguments expected by the selector is not one.|
|perform: aSymbol with: firstObject with: secondObject||Send the receiver the keyword message indicated by the arguments. The first argument, aSymbol, is the selector of the message. The other arguments, firstObject and secondObject, are the arguments of the message to be sent. Report an error if the number of arguments expected by the selector is not two.|
|perform: aSymbol with: firstObject with: secondObject with: thirdObject||Send the receiver the keyword message indicated by the arguments. The first argument, aSymbol, is the selector of the message. The other arguments, firstObject, secondObject, and thirdObject, are the arguments of the message to be sent. Report an error if the number of arguments expected by the selector is not three.|
|perform: selector withArguments: anArray||Send the receiver the keyword message indicated by the arguments. The argument, selector, is the selector of the message. The arguments of the message are the elements of anArray. Report an error if the number of arguments expected by the selector is not the same as the size of anArray.|
|Object instance protocol|
One way in which this protocol can be used is as a decoder of user commands. Suppose for example that we want to model a very simple calculator in which operands precede operators. A possible implementation represents the calculator as having (1) the current result, which is also the first operand, and (2) a possibly undefined second operand. Each operator is a message selector understood by the result. Sending the message clear, once, resets the operand; sending the message clear when the operand is reset will reset the result.
|instance variable names||result|
instance creation new ↑super new initialize
accessing result ↑result calculating apply: operator (self respondsTo: operator) ifFalse: [self error: 'operation not understood']. operand isNil ifTrue: [result ← result perform: operator] ifFalse: [result ← result perform: operator with: operand] clear operand isNil ifTrue: [result ← 0] ifFalse; [operand ← nil] operand: aNumber operand ← aNumber private initialize result ← 0
An example illustrates the use of the class Calculator.
hp ← Calculator new
Create hp as a Calculator. The instance variables are initialized with result 0 and operand nil.
hp operand: 3
Imagine the user has pressed the key labeled 3 and set the operand.
hp apply: #+
The user selects addition. The method for apply determines that the operator is understood and that the operand is not nil; therefore, the result is set by the expression
result perform: operator with: operand
which is equivalent to
0 + 3
The methods sets result to 3; operand remains 3 so that
hp apply: #+
again adds 3, so the result is now 6.
hp operand: 1. hp apply: #-. hp clear. hp apply: #squared
The result was 6, subtract 1, and compute the square; result is now 25.
System Primitive Messages
There are a number of messages specified in class Object whose purpose is to support the needs of the overall system implementation. They are categorized as system primitives. These are messages that provide direct access to the state of an instance and, to some extent, violate the principle that each object has sovereign control over storing values into its variables. However, this access is needed by the language interpreter. It is useful in providing class description/development utilities for the programming environment. Examples of these messages are instVarAt: anInteger and instVarAt: anInteger put: anObject which retrieve and store the values of named instance variables, respectively.
|become: otherObject||Swap the instance pointers of the receiver and the argument, otherObject. All variables in the entire system that pointed to the receiver will now point to the argument and vice versa. Report an error if either object is a SmallInteger.|
|instVarAt: index||Answer a named variable in the receiver. The numbering of the variables corresponds to the order in which the named instance variables were defined.|
|instVarAt: index put: value||Store the argument, value, into a named variable in the receiver. The number of variables corresponds to the order in which the named instance variables were defined. Answer value.|
|nextInstance||Answer the next instance after the receiver in the enumeration of all instances of this class. Answer nil if all instances have been enumerated.|
|numberOfPointers||Answer the number of objects to which the receiver refers.|
|refct||Answer the number of object pointers in the system that point at the receiver. Answer O if the receiver is a SmallInteger.|
|Object instance protocol|
Probably the most unusual and effective of the system primitive messages is the message become: otherObject. The response to this message is to swap the instance pointer of the receiver with that of the argument, otherObject. An example of the use of this message is found in the implementation of the message grow in several of the collection classes. The message grow is sent when the number of elements that can be stored in a (fixed-length) collection have to be increased without copyingthe collection; copying is undesirable because all shared references to the collection must be preserved. Thus a new collection is created, its elements stored, and then the original collection transforms into (becomes) the new one. All pointers to the original collection are replaced by pointers to the new one.
The following is the method for grow as specified in class SequenceableCollection.
grow | newCollection | newCollection ← self species new: self size + self growSize. newCollection replaceFrom: 1 to: self size with: self. ↑self become: newCollection growSize ↑10
Subclasses can redefine the response to the message growSize in order to specify alternative numbers of elements by which to expand.