On Tue, Jun 17, 2003 at 07:36:44PM -0700, Andres Valloud wrote:
> > I can follow Robert's suggestion and change the method names in my
> > code around so that the default would be to use strong references to
> > both the receiver and arguments, but you could use weak references
> > instead if you asked for them explicitly.
> > 
> > Meanwhile, does anyone else want to weigh in on this topic?
> 
> John put it extremely well already.  I couldn't agree more with him.  In
> fact, I used his code to convert all Squeak event systems to
> when:send:to:.  Once everything was converted, strong references made it
> easy to enforce zero memory leaks and reproduceable image size save
> after save after save.

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?  Which memory leaks that occur with weak
references are avoided by strong references?

> 
> If the intention to couple objects via event systems is explicit, so
> must be the intention of decoupling them at the appropriate time.

I object to the use of the word "must", as if there is some logical
implication.  I presume that you disagree with the following
statement?

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

I haven't thought about it deeply enough to have a firm opinion about
the best way to go (and it isn't an either-or choice, as Andreas' last
message notes), but both the weak and strong reference approaches have
benefits.  I find it convenient to not have to explicitly de-register
event recipients before they can be garbage-collected.  Having to do
this explicitly feels a bit like having to manage my memory explicitly.

My point is, we shouldn't rely on dogmas, but look at the benefits of 
identified approaches, and try to find one that incorporates as many
of them as possible.

Joshua


> 
> Andres.