Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!Germany.EU.net!donald!hasko
From: hasko@heeg.de (Hasko Heinecke)
Subject: Re: a cute hack -- delegation after doesNotUnderstand 
Message-ID: <CwsGMB.677@heeg.de>
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
References: <HULTQUIS.94Sep15140936@wk206.nas.nasa.gov>
Date: Tue, 27 Sep 1994 12:42:10 GMT
Lines: 62

In article <HULTQUIS.94Sep15140936@wk206.nas.nasa.gov> hultquis@nas.nasa.gov writes:
>We recently changed the method for doesNotUnderstand so
>that, before calling the debugger, it first checks if the
>receiving instance can provide us with one or more
>"delegate instances" which should receive the original
>method in its place.  If a delegate *is* provided, the
>system sends the original message to that object and the
>execution continues unimpeded.

This is called the "doesNotUnderstand:" hack in the Smalltalk community.
Some other people already pointed out that it has been used widely to
implement object proxies for distribution and database handling. However,
it is also known to be rather inefficient and bug-prone.

We chose to re-implement our product "ReomteObjects" for this reason, and
also because we needed to support distributed debugging. There is a
semantic difficulty in abusing exception handling for delegation when
an exception occurs in a _delegate_. Who should handle this, and how?

>This has proven to be extremely helpful, and has
>eliminated many of the occasions in which we would
>otherwise have wanted multiple-inheritance.

I have recently re-viewed a system which used this very technique for
implementing multiple inheritance. Well, I am biased against MI in whatever
hue it comes, but this was a case where MI obviously introduced more
problems than it solved. One reason was the complete lack of tools that
would indicate possible nameing conflicts in my class lettuce.

> For example,
>if we have a SET instance, we might choose to forward any
>unsupported messages to all of the elements within that
>set.  Thus, a set of WINDOW instances can be redrawn by
>sending the "redraw" message to the set itself.  The
>message-lookup fails and triggers the sending of the
>"doesNotUnderstand" message to the set.  That method now
>sends the message "delegate" to the same set, receives the
>list of delegate instances, and then sends the original
>message "redraw" to all of these instances.

Now say, 10% of your set's contents does not understand the "redraw"
message. Who handles these exceptions?

>Anyway, I think that this is a very cute and useful (and
>original?) hack, and that why I am posting it.  -- So that
>others might benefit from this idea, and perhaps so that
>someone might inform *me* of prior use of this technique
>or related uses of the doesNotUnderstand method.

The cute thing about Smalltalk and Lisp is, you can do a lot of things.
However, you should be careful about it, esp. when you simulate concepts
that were left out by the Smalltalk inventors for good reasons, like static
typeing of variables and parameters, or MI.

Well, I don't want to start another one of _these_ wars again... :-)

Hasko Heinecke
-- 
+-------------------------------------------------------+
| Hasko Heinecke speaking for myself only               |
| I _never_ mean what I say - and nobody else does...   |
+-------------------------------------------------------+
