This is interesting - apparently, you can execute a "super super" (starting as far up the chain as you like) in VisualWorks. Eliot Miranda
posted this in comp.lang.smalltalk:
perform: selector withArguments: anArray startingAbove: aBehavior
"Send the receiver the message indicated by the arguments, starting
the lookup in the superclass of aBehavior. The argument selector is
the selector of the message. The arguments of the message are the
elements of anArray. Invoke messageNotUnderstood: if the selector
is not understood by the receiver. Fail the primitive if aBehavior
is not the class of anObject or any of its superclasses, or if
anArray is not an Array with the same number of elements as the
number of arguments expected by the looked-up method."
<primitive: 515 errorCode: ec>
So to test that out, I defined a small hierarchy:
Each implements a method #foo, which prints to Transcript,
telling me who got executed. So, I ran these in a workspace:
son := Son new.
son perform: #foo withArguments: #() startingAbove: Son.
son perform: #foo withArguments: #() startingAbove: Dad
As expected, the first prints the result from class Son. The
second executes the one from class Dad, while the last line
executes the one from class Grandpa. Kind of neat, but this is
definitely a dangerous hack to rely on - especially if your runtime
can have new classes inserted into a hierarchy via dynamic