[FIX] sentTo: broken

Rick Zaccone zaccone at bucknell.edu
Wed May 10 11:31:31 UTC 2000


Thanks to everyone who responded to my questions.  I wanted to send
this out again with an appropriate subject line so that the folks at
Squeak Central will be aware of this problem.

Rick Zaccone

>> >> In his example, the proxy is for a Customer object.  The proxy overrides
>> >>doesNotUnderstand:.
>> >>Here's the code.
>> >>
>> >>doesNotUnderstand: aMessage
>> >>    |customer|
>> >>    customer := "materialize the customer".
>> >>    self become: customer.
>> >>    ^aMessage sendTo: self.   "redispatch!"
>> >>>
>> >Just a slight difference in dialects here. In Squeak you could say:
>> >
>> >       ^aMessage sentTo: self
>> >or
>> >       ^self perform: aMessage selector withArguments: aMessage arguments
>>
>> The two are currently not the same in Squeak. The former does not work (Yes
>> I tried it in 2.7) while the later does work. The problem is in the
>> implementation of sentTo:. We have:
>>
>> sentTo: receiver
>>
>>     lookupClass == nil
>>         ifTrue: [^ receiver perform: selector withArguments: args]
>>         ifFalse: [^ receiver perform: selector withArguments: args
>> inSuperclass: lookupClass]
>>
>> Asume we are using the above proxy code with sentTo: When sentTo: method is
>> run  the receiver is the customer object and the lookupClass is the Proxy
>> object.  So the ifFalse: block is run. So the only way this would work is
>> to have the proxy as a superclass of customer. But then we would create an
>> infinite loop, as the receiver tries to have the superclass execute the
>> method, which calls the doesNotUnderstand method in the proxy.....
>
>I ran into this a little while ago.  All you have to do is to change the
>lookupClass iVar in the Message object.  I was doing this in some
>proxies, but after reading the comments for the above method, we may as
>well extend the system to do what we want.  I have included an
>enhancement for Message which allows forwarding a Message to another
>class, without checking the lookupClass.  The method:
>#perform:withArguments:inSuperclass: looks like is allows you to start
>lookup in a class that isn't your concrete class, but 'we aren't going
>to need it' for proxies.
>
>the original override would be:
>
>> >>doesNotUnderstand: aMessage
>> >>    |customer|
>> >>    customer := "materialize the customer".
>> >>    self become: customer.
>> >>    ^aMessage forwardTo: self.   "redispatch!"
>
>I don't typically use become: either..
>
>I hope this helps,
>Rob
>
>, which uses the class of the receiver to start the lookup.
>> The example in the class comment of ObjectTracer is also broken due to the
>> sentTo: method in Message.
>>
>> Roger Whitney              Mathematical & Computer Sciences Department
>> whitney at cs.sdsu.edu        San Diego State University
>> http://www.eli.sdsu.edu/   San Diego, CA 92182-7720
>> (217) 328-0824
>> (619) 594-3535
>> (619) 594-6746 (fax)
>
>--
>--------------------------------------------------
>Smalltalking by choice.  Isn't it nice to have one!
>--------------F342E7A110612304DD3C2A1C
>Content-Type: text/plain; charset=us-ascii;
> name="ForwardMsgSend.2.cs"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="ForwardMsgSend.2.cs"
>
>'From Squeak2.7 of 5 January 2000 [latest update: #1762] on 10 May 2000 at 1:22:03 am'!
>
>!Message methodsFor: 'sending' stamp: 'tfei 5/10/2000 01:21'!
>forwardTo: receiver
>	"answer the result of sending this message to receiver"
>
>	^ receiver perform: selector withArguments: args! !





More information about the Squeak-dev mailing list