FW: Bug in class message behaviour
Bob Arning
arning at charm.net
Wed Aug 23 16:13:03 UTC 2000
On Wed, 23 Aug 2000 16:23:10 +0200 "Roel Wuyts" <rwuyts at vub.ac.be> wrote:
>I want to override the behaviour of the #class message. However, this
>doesn't seem to work. The execution seems to jump my own definition of
>#class and automatically proceeds to the #class primitive in Object.
>
>The real strange thing is when stepping through the execution using the
>debugger, then my own #class method gets executed. Or if I send the
>message: 'perform: #class', then my own #class method also gets executed,
>as it should be.
Roel (and Johan),
Certain message sends are encoded as single bytecodes and executed as primitives for purposes of space and speed. Those are:
#(#+ #- #< #> #<= #>= #= #~= #* #/ #\\ #@ #bitShift: #// #bitAnd: #bitOr: #at: #at:put: #size #next #nextPut: #atEnd #== #class #blockCopy: #value #value: #do: #new #new: #x #y).
Of these, there are three variations:
- those that always do a normal send (#next e.g.)
- those that work as a primitive if the receiver and argument are the right type, but do a normal send otherwise (#+ e.g.)
- those that always work as a primitive (#== and #class)
When you step through the code in the debugger, however, then they all become normal sends. The net result is that some of these methods (#== and #class for anything and others under certain circumstances like #+ for SmallInteger receiver and argument) cannot be overridden.
Cheers,
Bob
P.S. Roel - let me know if you get this. My ISP was unable to resolve 'vub.ac.be'.
More information about the Squeak-dev
mailing list
|