Hi.

> I'm confused.  Don't strong references lead to "memory leaks" when
> you forget to remove the event registration, and objects that you
> thought would be GCed are not?

Exactly.  Instant debugging material, which results in better
understanding and a better implementation or design.  See John's email,
it's a great explanation already.

<><><><><><><><><
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.
<><><><><><><><><

> "If the intention to allocate memory via object instantiation is
> explicit, so must be the intention of deallocating it at the
> appropriate time."

It depends - who is saying this?  This is fine as far as the VM is
concerned, but it seems to me that we're past the point where we think
in terms of allocating memory when we send new.  That's the beauty of
pushing memory management to the VM, it just can't stand in your way.

Andres.