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