Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tektronix!psueea!parsely!bucket!servio!bruce
From: bruce@servio.UUCP (Bruce Schuchardt)
Newsgroups: comp.lang.smalltalk
Subject: Re: Tracking Interaction Histories
Message-ID: <162@servio.UUCP>
Date: 21 Aug 89 18:33:24 GMT
References: <56231@aerospace.AERO.ORG> <56248@aerospace.AERO.ORG> <34138@apple.Apple.COM>
Reply-To: bruce@servio.UUCP (Bruce Schuchardt)
Organization: Servio Logic Development Corp.; Beaverton, OR
Lines: 55

In article <34138@apple.Apple.COM> bnfb@Apple.COM (Bjorn Freeman-Benson) writes:
>In article <56248@aerospace.AERO.ORG> (Russell J. Abbott) writes:
>> ...
>>objects messages to be passed on to the variable's referent.  But in
>>order for the variable to be able to do that it has to have built into
>>it selectors for all the possible calls it's referents may ever receive,
>
>You can do this by reimplementing 
>    doesNotUnderstand: aMessage
>for your Variable class.  When an object gets sent a message that it
>does not have a method for, it calls this routine.  The default
>behavior (in Object) is to put up an error notification.  For your
>Variable class, the method would be:
>    doesNotUnderstand: aMessage
>	^referent perform: aMessage selector withArguments: aMessage arguments
>
>And then, of course, you get into the problem of "the name of a
>thing" versing itself".  When you send "getReferent" to the Variable
>it handles the message.  But what if you wanted to send
>"getReferent" to the Variable's referent?  Arg.
>

There are some pitfalls in using proxy objects like this that you should
be aware of.  The first is *speed degradation*.  The second is *special
messages*.

When you use the "doesNotUnderstand:" route of trapping messages, you are
introducing some serious extra processing into your system.  The interpreter
must hunt through the forwarder's class hierarchies method dictionaries
to determine that the message has not been implemented.  It must then build
a message object (to hold the selector and arguments) and search the
hierarchy again for your "doesNotUnderstand:" method.

I would not recommend using this approach for compute-intensive applications.
In any case, it can be made most efficient by nilling out the superclass
of the forwarder class after it has been created.  This is more work, but
you will end up with a faster forwarder.

The second problem concerns special messages.  You all probably saw the
message last week about the "value" method in contexts.  In Smalltalk-80,
and evidently Smalltalk/V, some messages are treated extra special by the
compiler/interpreter.  They don't go through message lookup, but are
trapped and executed immediately.  Examples are "value" and "==".
ParcPlace Smalltalk-80 keeps a list of special selectors in a class
variable in SystemDictionary.  YOU WILL NOT BE ABLE TO TRAP THESE
MESSAGES unless you change the compiler or recompile everything to use
different selectors.



-- 
 --------                         --------------
| Bruce Schuchardt          Ph: (503) 629-8383  |
| Beaverton, OR             uunet!servio!bruce  |
 --------------                         --------