Smalltalk80LanguageImplementation:Chapter 06
- Chapter 6 Protocol for all Objects
Protocol for all Objects
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
Everything in the system is an object. The protocol common to all objects in the system is provided in the description of class Object. This means that any and every object created in the system can respond to the messages defined by class Object. These are typically messages that support reasonable default behavior in order to provide a starting place from which to develop new kinds of objects, either by adding new messages or by modifying the response to existing messages. Examples to consider when examining Object's protocol are numeric objects such as 3 or 16.23, collections such as 'this is a string' or #(this is an array), nil or true, and class-describing objects such as Collection or SmallInteger or, indeed, Object itself.
The specification of protocol for class Object given in this chapter is incomplete. We have omitted messages pertaining to message handling, special dependency relationships, and system primitives. These are presented in Chapter 14.
Testing the Functionality of an Object
Every object is an instance of a class. An object's functionality is determined by its class. This functionality is tested in two ways: explicit naming of a class to determine whether it is the class or the superclass of the object, and naming of a messageselector to determine whether the object can respond to it. These reflect two ways of thinking about the relationship among instances of different classes: in terms of the class/subclass hierarchy, or in terms of shared message protocols.
| testing functionality | |
| class | Answer the object which is the receiver's class. |
| isKindOf: aClass | Answer whether the argument, aClass, is a superclass or class of the receiver. |
| isMemberOf: aClass | Answer whether the receiver is a direct instance of the argument, aClass. This is the same as testing whether the response to sending the receiver the message class is the same as (==) aClass. |
| respondsTo: aSymbol | Answer whether the method dictionary of the receiver's class or one of its superclasses contains the argument, aSymbol, as a messageselector. |
| Object instance protocol | |
Example messages and their corresponding results are
| expression | result |
| 3 class | SmallInteger |
| #(this is an array) isKindOf: Collection | true |
| #(this is an array) isMemberOf: Collection | false |
| #(this is an array) class | Array |
| 3 respondsTo: #isKindOf: | true |
| #(1 2 3) isMemberOf: Array | true |
| Object class | Object class |
Comparing Objects
Since all information in the system is represented as objects, there is a basic protocol provided for testing the identity of an object and for copying objects. The important comparisons specified in class Object are equivalence and equality testing. Equivalence ( == ) is the test of whether two objects are the same object. Equality ( = ) is the test of whether two objects represent the same component. The decision as to what it means to be "represent the same component" is made by the receiver of the message; each new kind of object that adds new instance variables typically must reimplement the = message in order to specify which of its instance variables should enter into the test of equality. For example, equality of two arrays is determined by checking the size of the arrays and then the equality of each of the elements of the arrays; equality of two numbers is determined by testing whether the two numbers represent the same value; and equality of two bank accounts might rest solely on the equality of each account identification number.
The message hash is a special part of the comparing protocol. The response to hash is an integer. Any two objects that are equal must return the same value for hash. Unequal objects may or may not return equal values for hash. Typically, this integer is used as an index to locate the object in an indexed collection (as illustrated in Chapter 3). Anytime = is redefined, hash may also have to be redefined in order to preserve the property that any two objects that are equal return equal values for hash.
| comparing | |
| == anObject | Answer whether the receiver and the argument are the same object. |
| = anObject | Answer whether the receiver and the argument represent the same component. |
| ~= anObject | Answer whether the receiver and the argument do not represent the same component. |
| ~~ anObject | Answer whether the receiver and the argument are not the same object. |
| hash | Answer an Integer computed with respect to the representation of the receiver. |
| Object instance protocol | |
The default implementation of = is the same as that of ==.
Some specialized comparison protocol provides a concise way to test for identity with the object nil.
| testing | |
| isNil | Answer whether the receiver is nil. |
| notNil | Answer whether the receiver is not nil. |
| Object instance protocol | |
These messages are identical to == nil and ~~ nil, respectively. Choice of which to use is a matter of personal style.
Some obvious examples are
| expression | result |
| nil isNil | true |
| true notNil | true |
| 3 isNil | false |
| #(a b c) = #(a b c) | true |
| 3 = (6/2) | true |
| #(1 2 3) class == Array | true |
Copying Objects
There are two ways to make copies of an object. The distinction is whether or not the values of the object's variables are copied. If the values are not copied, then they are shared (shallowCopy); if the values are copied, then they are not shared (deepCopy).
| copying | |
| copy | Answer another instance just like the receiver. |
| shallowCopy | Answer a copy of the receiver which shares the receiver's instance variables. |
| deepCopy | Answer a copy of the receiver with its own copy of each instance variable. |
| Object instance protocol | |
The default implementation of copy is shallowCopy. In subclasses in which copying must result in a special combination of shared and unshared variables , the method associated with copy is usually reimplemented , rather than the method associated with shallowCopy or deepCopy.
As an example, a copy (a shallow copy) of an Array refers to the same elements as in the original Array, but the copy is a different object. Replacing an element in the copy does not change the original. Thus
| expression | result |
| a ← #('first' 'second' 'third') | ('first' 'second' 'third') |
| b ← a copy | ('first' 'second' 'third') |
| a = b | true |
| a == b | false |
| (a at: 1) == (b at: 1) | true |
| b at: 1 put: 'newFirst' | 'newFirst' |
| a = b | false |
| a ← 'hello' | 'hello' |
| b ← a copy | 'hello' |
| a = b | true |
| a == b | false |
Figure 6.1 shows the relationship between shallow and deep copying. Tofurther illustrate the distinction between shallowCopy and deepCopy, take as an example a PersonnelRecord Suppose it is defined to include the variable insurancePlan, an instance of class insurance. Suppose further that each instance of Insurance has a value associated with it representing the limit on medical coverage. Now suppose we have created employeeRecord as a prototypical instance of a PersonnelRecord. By "prototypical" we mean that the object has all of the initial attributes of any new instance of its class, so that instances can be created by simply copying it rather than sending a sequence of initialization messages. Suppose further that this prototypical instance is a class variable of PersonnelRecord and that the response to creating a new PersonnelRecord is to make a shallow copy of it; that is, the method associated with the message new is ↑employeeRecord copy.
As a result of evaluating the expression
joeSmithRecord ← PersonnelRecord new
joeSmithRecord refers to a copy (in particular, a shallow copy) of employeeRecord.
The prototype employeeRecord and the actual record joeSmithRecord share a reference to the same insurance plan. Company policy may change. Suppose PersonnelRecord understands the message changeInsuranceLimit: aNumber, which is implemented by having the prototypical instance of PersonnelRecord, empioyeeRecord, reset its insurance plan limit on medical coverage. Since this insurance plan is shared, the result of evaluating the expression
PersonnelRecord changeInsuranceLimit: 4000
is to change the medical coverage of all employees. In the example, both the medical coverage referenced by employeeRecord and that referenced by its copy, joeSmithRecord, is changed. The message changeInsuranceLimit: is sent to the class PersonnelRecord because it is the appropriate object to broadcast a change to all of its instances.
Accessing the Parts of an Object
There are two kinds of objects in the Smalltalk-80 system, objects with named variables and objects with indexed variables. Objects with indexed variables may also have named instance variables. This distinction is explained in Chapter 3. Class Object supports six messages intended to access the indexed variables of an object. These are
| accessing | |
| at: index | Answer the value of the indexed instance variable of the receiver whose index is the argument, index. If the receiver does not have indexed variables, or if the argument is greater than the number of indexed variables, then report an error. |
| at: index put: anObject | Store the argument, anObject, as the value of the indexed instance variable of the receiver whose index is the argument, index. If the receiver does not have indexed variables, or if the argument is greater than the number of indexed variables, then report an error. Answer anObject. |
| basicAt: index | Same as at: index. The method associated with this message, however, cannot be modified in any subclass. |
| basicAt: index put: anObject | Same as at: index put: anObject. The method associated with this message, however, cannot be modified in any subclass. |
| size | Answer the receiver's number of indexed variables. This value is the same as the largest legal index. |
| basicSize | Same as size. The method associated with this message, however, cannot be modified in any subclass. |
| Object instance protocol | |
Notice that the accessing messages come in pairs; one message in each pair is prefixed by the word basic meaning that it is a fundamental system message whose implementation should not be modified in any subclass. The purpose of providing pairs is so that the external protocol, at:, at:put:, and size, can be overridden to handle special cases, while still maintaining a way to get at the primitive methods. (Chapter 4 includes an explanation of "primitive" methods, which are methods implemented in the virtual machine for the system.) Thus in any method in a hierarchy of class descriptions, the messages, basicAt:, basicAt:put:, and basicSize, can always be used to obtain the primitive implementations. The message basicSize can be sent to any object; if the object is not variable length, then the response is 0.
Instances of class Array are variable-length objects. Suppose letters is the Array #(a b d f j m p s). Then
| expression | result |
| letters size | 8 |
| letters at: 3 | d |
| letters at: 3 put: #c | c |
| letters | (a b c f j m p s) |
Printing and Storing Objects
There are various ways to create a sequence of characters that provides a description of an object. The description might give only a clue as to the identity of an object. Or the description might provide enough information so that a similar object can be constructed. In the first case (printing), the description may or may not be in a well-formatted, visually pleasing style, such as that provided by a Lisp pretty-printing routine. In the second case (storing), the description might preserve information shared with other objects.
The message protocol of the classes in the Smalltalk-80 system support printing and storing. The implementation of these messages in class Object provides minimal capability; most subclasses override the messages in order to enhance the descriptions created. The arguments to two of the messages are instances of a kind of Stream; Streams are presented in Chapter 12.
| printing | |
| printString | Answer a String whose characters are a description of the receiver. |
| printOn: aStream | Append to the argument, aStream, a String whose characters are a description of the receiver. |
| storing | |
| storeString | Answer a String representation of the receiver from which the receiver can be reconstructed. |
| storeOn: aStream | Append to the argument, aStream, a String representation of the receiver from which the receiver can be reconstructed. |
| Object instance protocol | |
Each of the two kinds of printing is based on producing a sequence of characters that may be shown on a display screen, written on a file, or transferred over a network. The sequence created by storeString or storeOn: should be interpretable as one or more expressions that can be evaluated in order to reconstruct the object. Thus, for example, a Set of three elements, $a, $b, and $c, might print as
Set ($a $b $c)
while it might store as
(Set new add: $a, add: $b, add: $c)
Literals can use the same representation for printing and storing. Thus the String 'hello' would print and store as 'hello'. The Symbol #name prints as name, but stores as #name.
For lack of more information, the default implementation of printString is the object's class name; the default implementation of storeString is the class name followed by the instance creation message basicNew, followed by a sequence of messages to store each instance variable. For example, if a subclass of Object, say class Example, demon-strated the default behavior, then, for eg, an instance of Example with no instance variables, we would have
| expression | result |
| eg printString | 'an Example' |
| eg storeString | '(Example basicNew)' |
Error Handling
The fact that all processing is carried out by sending messages to objects means that there is one basic error condition that must be handled by the system: a message is sent to an object, but the message is not specified in any class in the object's superclass chain. This error is determined by the interpreter whose reaction is to send the original object the message doesNotUnderstand: aMessage. The argument, aMessage, represents the failed messageselector and its associated arguments, if any. The method associated with doesNotUnderstand: gives the user a report that the error occurred. How the report is presented to the user is a function of the (graphical) interface supported by the system and is not specified here; a minimum requirement of an interactive system is that the error message be printed on the user's output device and then the user be given the opportunity to correct the erroneous situation. Chapter 17 illustrates the Smalltalk-80 system error notification and debugging mechanisms.
In addition to the basic error condition, methods might explicitly want to use the system error handling mechanism for cases in which a test determines that the user program is about to do something unacceptable. In such cases, the method might want to specify an error comment that should be presented to the user. A typical thing to do is to send the active instance the message error: aString, where the argument represents the desired comment. The default implementation is to invoke the system notification mechanism. The programmer can provide an alternative implementation for error: that uses application-dependent error reporting.
Common error messages are supported in the protocol of class Object. An error message might report that a system primitive failed, or that a subclass is overriding an inherited message which it can not support and therefore the user should not call upon it, or that a superclass specifies a message that must be implemented in a subclass.
| error handling | |
| doesNotUnderstand: aMessage | Report to the user that the receiver does not understand the argument, aMessage, as a message. |
| error: aString | Report to the user that an error occurred in the context of responding to a message to the receiver. The report uses the argument, aString, as part of the error notification comment. |
| primitiveFailed | Report to the user that a method implemented as a system primitive has failed. |
| shouldNotImplement | Report to the user that, although the superclass of the receiver specifies that a messageshould be implemented by subclasses, the class of the receiver cannot provide an appropriate implementation. |
| subclassResponsibility | Report to the user that a method specified in the superclass of the receiver should have been implemented in the receiver's class. |
| Object instance protocol | |
A subclass can choose to override the error-handling messages in order to provide special support for correcting the erroneous situation. Chapter 13, which is about the implementation of the collection classes, provides examples of the use of the last two messages.