mark@apple.UUCP (Mark Lentczner) (02/18/86)
[]
It is true of all message sends that have special byte codes
that the interpreter will execute some compilied version of
the code no matter what you write in the methods. As to
whether you can override the behavior in subclasses or not
depends on both the message involved and the interpreter.
Our interpreter, for the Macintosh, checks the class of the
receiving object for many of the bytecode sends and will do
an actual send if the class doesn't match. Hence subclass-
ing point and overriding
In general, in our implementation, we've tried to keep the
won't work cases down to only those you really don't want to
redefine anyway (redefining @ for point can be VERY
dangerous), however it does sometimes get in the way, for
example, == can NEVER be overridden in our system (in all
others I know about too) and hence it is difficult to make a
class of objects that behaves exactly like one of its
instance variables (like proxy object for something on a
network).
--
--Mark Lentczner
Apple Computer
UUCP: {nsc, dual, voder, ios}!apple!mark
CSNET: mark@Apple.CSNETrentsch@unc.UUCP (Tim Rentsch) (02/21/86)
In article <21930@apple.UUCP> mark@apple.UUCP (Mark Lentczner) writes: > It is true of all message sends that have special byte codes that the > interpreter will execute some compilied version of the code no matter > what you write in the methods. As to whether you can override the > behavior in subclasses or not depends on both the message involved > and the interpreter. Yes, but.... which ones do or don't is part of the specification of the virtual machine ("No lookup"), and, if I'm not mistaken, at:put: in class Array is not one of those. In any case, the at:put: which was not looked up was in a *subclass* of Array. Mark's point about == and proxy objects was interesting. This argues for really *everything* being sent as a message. cheers, Tim Rentsch