Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!news.mathworks.com!news.kei.com!news.texas.net!news.sprintlink.net!news-fw-6.sprintlink.net!judith.state.net!technix!fourthgen!usenet
From: Clyde Cutting <cutting@fourthgen.com>
Subject: Re: A Suggestion to Smalltalk Language (Inspired by Java)
Content-Type: text/plain; charset=us-ascii
To: cutting
Sender: usenet@fourthgen.fourthgen.com (Charlie Root)
Content-Transfer-Encoding: 7bit
Nntp-Posting-Host: slip129
Organization: Fourth Generation, Inc.
Message-ID: <Duq39J.BHC.E.fourthgen@fourthgen.fourthgen.com>
References: <31E22B95.2842@wwa.com> <4sid38$84i$1@mhafc.production.compuserve.com>
X-Mailer: Mozilla 1.1PE (Windows; I; 16bit)
Mime-Version: 1.0
Date: Thu, 18 Jul 1996 05:00:55 GMT
Lines: 55

Susan B. Macchia  <74454.3256@CompuServe.COM> wrote:
>>[Author missing:]
>>Please note, if you make the superclass of your proxy be nil 
>>(rather than Object) then you do not have to override "almost 
>>every method".
>
>I wouldn't necessarily say that subclassing the proxy from nil is 
>the "right" way to build a proxy.  It is very useful for simple 
>real subjects and for quickly creating a proxy and prototyping 
>its use.  However, I have found that when the real subject is 
>complicated, this makes for very difficult debugging and many 
>unanticipated side effects.  I prefer to hand craft the proxy when 
>the subject is complicated; I find it far easier to debug and that 
>the side effects can be reduced (not to mention tracking down 
>those side effects and correcting the problem).
>
>Just another point of view.
>
>Susan Macchia
>SBM Consulting

I agree whole-heartedly! The real problem is the original overriding of
doesNotUnderstand:, not the subclassing from Object instead of nil.

There are only two reasons for REAL proxies that I can think of right
now. REAL meaning a truly anonymous object acting as a generic
"false-front" or intermediary to a completely replaceable (unknown type)
target (aka subject) object. 1) as a handle to a distributed object, and
2) as a handle to an object still in persistent storage--which is really
just a variation on #1. (And in these cases I would agree that you
probably are better off subclassing from nil.)

But in most cases I see people override doesNotUnderstand: in order to
save themselves from re-implementing a relatively small interface to
a known set of collaborating (aka subject, target) objects. What this
means is that every message will get forwarded and the *actual*
interface that a collaborating object will be expected to support is
*infinite*!!! Now, this clearly violates all standards of good design.
If you don't know what interface your collaborators will need to support,
then you need to do some more design.

Susan, I particularly like your comments about complicated subjects.
I've been pragmatic: the more complicated the subject and greater the
additional work of building the real interface, the less pedantic I've
been about not overriding doesNotUnderstand:. But you explain how the
shortcut is *not* the pragmatic route, which appeals to my sense of
artistic software design--yes, there is harmony in the universe...

----- -- -------
Clyde E. Cutting                           Fourth Generation, Inc.
Object Technology Consultant               Galtier Plaza, Suite 430
mailto:cutting@fourthgen.com               St. Paul, MN 55101-2901
http://www.fourthgen.com/~cutting          (612) 224-5339


