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