Path: utzoo!attcan!uunet!mcsun!ukc!icdoc!qmc-cs!eliot
From: eliot@cs.qmc.ac.uk (Eliot Miranda)
Newsgroups: comp.lang.smalltalk
Subject: Re: Tracking Interaction Histories
Message-ID: <1194@sequent.cs.qmc.ac.uk>
Date: 24 Aug 89 17:46:32 GMT
References: <56231@aerospace.AERO.ORG> <56248@aerospace.AERO.ORG> <34138@apple.Apple.COM> <162@servio.UUCP>
Reply-To: eliot@cs.qmc.ac.uk (Eliot Miranda)
Organization: Computer Science Dept, Queen Mary College, University of London, UK.
Lines: 55
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <162@servio.UUCP> bruce@servio.UUCP (Bruce Schuchardt) writes:
>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*.

                .....

>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.


It isn't necessarily the case that you can't trap special
selector messages in Smalltalk-80. he blue-book specification
implements the == and class messages directly without a lookup.
 All other special selector messages are defined to workwithout
a lookup only for specific class-selector pairs, e.g. BlockContext
and value.

Both PPS's Smalltalk-80 VM & my BrouHaHa Smalltalk-80 VM will
only execute == and class for a small set of classes that are
known and used by the VM, e.g. Array, Message, SmallInteger,
MethodContext, True etc.

At QMC we have used encapsulators for inter-machine
communication & monitor objects (encapsulators that use a
critical section to serialise message sends to the object they
wrap up).

The BrouHaHa VM also caches doesNotUnderstand: message lookups
in the message lookup cache so that nopt every message that
will not be understood will be looked up.
(sounds complete gobbledegook I'm sure!)

In summary, there is no reason why encapsulators should be a
performance bottleneck.  Almost everything can be optimised!


-- 
Eliot Miranda				email:		eliot@cs.qmc.ac.uk
Dept of Computer Science		Tel:		01 975 5220
Queen Mary Westfield College		International:	+44 1 975 5220
Mile End Road
LONDON E1 4NS