Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1.chuqui 4/7/84; site apple.UUCP
Path: utzoo!linus!decvax!decwrl!sun!idi!apple!mark
From: mark@apple.UUCP (Mark Lentczner)
Newsgroups: net.lang.st80
Subject: at:put: not doing what is expected
Message-ID: <21930@apple.UUCP>
Date: Tue, 18-Feb-86 00:07:13 EST
Article-I.D.: apple.21930
Posted: Tue Feb 18 00:07:13 1986
Date-Received: Wed, 19-Feb-86 23:38:21 EST
References: <1@randvax.UUCP> <975@unc.unc.UUCP>
Reply-To: mark@apple.UUCP (Mark Lentczner)
Distribution: net
Organization: Apple Education Research Group, Cupertino CA
Lines: 27

[]
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.CSNET