Exactly right.  As a side note, if we would stop adding methods to
ProtoObject we wouldn't need to implement them on our proxy subclasses
to simulate a DNU.  #ifNil:, #ifNotNil: and other convenience methods
totally go against the nature of ProtoObject.

On 9/28/07, Hans-Martin Mosner <hmm at heeg.de> wrote:
> Colin Putney schrieb:
> >
> > On Sep 27, 2007, at 9:46 PM, Alejandro Martínez wrote:
> >
> >> I was thinking about implementing a Proxy but instead the usual way
> >> which I believe is subclassing from ProtoObject, I subclassed from
> >> Object a ProxyObject with an iVar called encapsulatedObject, and then
> >> write
> >>
> >> ProxyObject >>doesNotUnderstand: aMessage
> >>     ^aMessage sendTo: self encapsulatedObject
> >>
> >> Then for every message I need to intercept, I write:
> >>
> >> ProxyObject >>at: index put: value
> >>     ^self doesNotUnderstand: (Message selector: #at:put:
> >>                                                          arguments:
> >> (Array with: index with: value)).
> >
> > There's no need to do this kind of thing. If your ProxyObject class
> > doesn't implement #at:put: the VM will create the Message object for
> > you and send #doesNotUnderstand: to your proxy. You only need to
> > implement the messages you *don't* want forwarded.
> >
> > Colin
> >
> >
> >
> That's not correct in his situation - since #at:put: is implemented in
> the superclass (Object) it will be used. Your approach works only if he
> subclasses from ProtoObject.
> Alejandro, the information you got from Stephane's book is probably a
> bit outdated (we would have done it that way in the old days). The
> ProtoObject approach is cleaner since ProtoObject implements only those
> messages which are considered necessary in any object in the system.
> Looking at it in the browser, I think it still implements too much, so
> you still would have to implement some messages in your ProxyObject.
>
> Cheers,
> Hans-Martin
>
>