Smalltalk and Object Orientation: an Introduction - Free

we cannot tell from this line alone, what action the object will perform. The mechanism essentially
allows the method name, as well as the object, to be held in a variable. For example,
is equivalent to:
aVariable := #size.
aCollection perform: aVariable.
aCollection size.
The contents of the variable passed with the perform: message must be a symbol, otherwise an
error will be generated. It must also be a legal message otherwise an error will also be generated. For
example, if the variable contained the symbol #abcd, then that would be equivalent to e valuating
aCollection abcd. Unless this message is defined for this class of object, then the message will
generate a “not understood” exception (whether it is sent directly or as part of a perform message).
The perform mechanism can also handle methods which take arguments. The arguments are handled
by different versions of the perform: message:
1. for methods with one argument use perform:with:
2. for methods with two arguments use perform:with:with:
3. for methods with three arguments use perform:with:with:with:
4. for methods with more than three arguments use perform:withArguments: where the
arguments are assumed to be in an array.
For example,
anObject perform: aSymbol with: anotherObject.
anObject perform: aSymbol with: object1 with: object2.
anObject perform: aSymbol with: object1 with: object2 with: object3.
anObject perform: aSymbol withArguments: aCollection
Note that the symbol held in aSymbol will be the message selector name. That is, if the message to
be sent would normally be written as:
anObject at: 2 out: 5.
then with the perform mechanism this would be written as:
aSymbol := #at:put:
object1 := 2.
object2 := 5.
anObject perform: aSymbol with: object1 with: object2.
The perform mechanism is very powerful and provides a great deal of flexibi lity. However, in most
normal situations you should not need to use it. Indeed, there are a number of points to remember when
thinking about using the perform mechanism. The first is that it is less efficient than directly sending a
message to an object. T he second is that it can be more difficult to maintain as it is not immediately
obvious what message is being sent to the object. Thirdly, it can be an awful lot harder to debug code
containing perform: messages. This is because the system back trace displ ayed in the debugger may
not display the same chain of message sends that the user of the class expects.
So where should you use it? The situations where you are likely to encounter it are almost all
associated with the user interface. However, you should not try to avoid it just because it may be less
efficient at run time and more difficult to debug. There may be situations in which the perform
mechanism can allow the construction of very powerful and flexible frameworks. The important point
to note is that in this situation there may be a trade off between flexibility and efficiency.
25.3 The Dependency mechanism
There are a number of different relationships between objects in the Smalltalk environment which we
have already looked at. In particular we have considered:
206