Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!apple!usc!ginosko!uunet!zephyr.ens.tek.com!tektronix!psueea!parsely!bucket!servio!bruce
From: bruce@servio.UUCP (Bruce Schuchardt)
Newsgroups: comp.lang.smalltalk
Subject: Re: Performance of "doesNotUnderstand:"
Message-ID: <163@servio.UUCP>
Date: 28 Aug 89 15:59:33 GMT
References: <9070@june.cs.washington.edu>
Reply-To: bruce@servio.UUCP (Bruce Schuchardt)
Organization: Servio Logic Development Corp.; Beaverton, OR
Lines: 29

It was nice to see a concrete example with _real_ timing figures in 
John Maloney's message.  He is right that it is dangerous to nil out
the superclass of a class, but I would not agree with him that you
can't do it at all.  If your "doesNotUnderstand:" method does not break,
there is no reason for the Smalltalk interpreter to take a nose-dive.
A few messages will not go to your "doesNotUnderstand:" method, but
these are handled w/o message sends anyway so you don't have to worry
about them (unless you care that you can't catch them and forward them).
For ParcPlace Smalltalk (v2.3 - I haven't done this work with 2.4 or
2.5 yet), you should consider implementing "refCt" and "==" in your
forwarder class.

There is a lot more I can say on this topic if anyone is interested.
I do want to warn you to (1) Watch the return value
of your "doesNotUnderstand:" method so that you don't return the
object you are forwarding for.  E.g.,

    result _ myObject perform: aMessage selector
               withArguments: aMessage arguments.
    ^ (result == myObject) ifTrue: [self]  ifFalse: [result]

and (2) put code in the debugger to stick the superclass back into
your forwarder class(es) before the context chain is walked to form
the stack list.  This can be done in ProcessHandle in ParcPlace Smalltalk.
-- 
 --------                         --------------
| Bruce Schuchardt          Ph: (503) 629-8383  |
| Beaverton, OR             uunet!servio!bruce  |
 --------------                         --------