My vote is for regular MessageSend objects. (That's why I used them. 
:-}>) Having used this mechanism extensively since Steve Messick 
introduced it in Smalltalk/V Mac 2.0, I have found that the time spent 
figuring out where dependencies should be released invariably led to 
improvements in my design and a better understanding of the temporal 
dependencies of the subsystems. I have found this to be the case with 
the original changed/update mechanism as well.

In my experience, loose coupling defines a de facto session of 
observation. Making the (de)registration explicit forces the designer 
to be aware of a session of observation and when that session begins 
and ends. This becomes particularly important in distributed systems in 
which observation may be occurring over remote links. I know from 
experience that explicit registration and deregistration as the 
demarcation of session boundaries is extraordinarily useful in these 
contexts.

Most of the arguments I have heard for weak registrations fall in the 
camp of "I don't want to think about the consequences of 
dependency...". In over a decade of use, I have never had the need for 
weak dependents.

Cheers,
John Sarkela
[ :me | 'Sir ', me, ' of the Square Bracket'] value: ':-}>'

On Monday, June 16, 2003, at 08:14 AM, Robert Withers wrote:

>
> On Monday, June 16, 2003, at 04:18 AM, Chris Burkert wrote:
>
>> Could we now do something about it? I don't wanna override the events 
>> code and the only difficult part to change it is to agree on the 
>> names for the messages I think.
>
> Chris, for now you can use the #when:evaluate: registration method and 
> specify a regular MessageSend.  So, you would have:
>
> r := RectangleMorph new openInWorld.
> o := Object new.
> o when: #a evaluate: (MessageSend receiver: r selector: #color: 
> argument: (Color black alpha: 0.3)).
>
>
> On Sunday, June 15, 2003, at 11:13 PM, Ned Konz wrote:
>
>> The problem is that the WeakMessageSends we're using (well, my name is
>> all over this, so I guess I'm responsible) hold on to their receiver
>> *and* their arguments weakly.
>
> Ned, I am equally responsible for this and probably more so since it 
> was primarily my argument to include this "feature".  IIRC, our 
> interest was to help the developer avoid having to explicitly 
> deregister event registrations, since it can be a common source of 
> uncollected garbage.  Static typing is also supposed to help the 
> developer...
>
>> We've discussed this at length in the past (like back on February 9)
>> and never really did anything about it.
>
> This really doesn't work as well as I had hoped.  We probably ought to 
> revert back to the original mechanism which uses regular MessageSends. 
>  What do people think about this?  This would just require us to 
> change 3 methods.
>
> so much for strongly held opinions...  :-/
>
> Rob
>