David Bruant wrote:
> Le 27/07/2013 20:27, Brendan Eich a écrit :
>> Weak refs are necessary for observer patterns, as we've discussed ad 
>> nauseum.
> That's not the conclusion I took from these discussions. As I feel 
> words are important, the conclusions I took are:
> WeakRefs are *necessary* for distributed acyclic garbage collection. 
> They are only *convenient* for observer patterns: people can always 
> unsubscribe their listeners or use another equivalent ".dispose() 
> protocol" (assuming the API has been thought with that in mind which 
> it is not always).

You seemed to concede my point from

https://mail.mozilla.org/pipermail/es-discuss/2013-February/028572.html

"""

... Real systems such as COM, XPCOM, Java, and C#
support weak references for good reasons. One cannot do "data binding"
transparently without either making a leak or requiring manual dispose
(or polling hacks), precisely because the lifecycle of the model and
view data are not known to one another, and should not be coupled.

Seehttp://wiki.ecmascript.org/doku.php?id=strawman:weak_refs  intro, on
the observer and publish-subscribe patterns.

"""

and

https://mail.mozilla.org/pipermail/es-discuss/2013-February/028575.html

"""

David Bruant wrote:
>/  A view knows own its lifecycle, it involves adding observers in a
/>/  bunch of places. When the view lifecycle comes to an end for whatever
/>/  reason, it only makes sense that it removes the observers it added.
/
The problem is that the notification comes from a model object to the
view via the observer. If the view holds the model object strongly, it
can entrain the entire model. And if there is an association from model
to view somewhere (which is not unreasonable, in a mostly self-hosted
system), then....

/be

"""

with confirmation from Rafael Weinstein:

https://mail.mozilla.org/pipermail/es-discuss/2013-March/028918.html

"This is exactly right."

In the large, there's no single controller who can manaully dispose of 
everything and avoid leaks. This has been rediscovered many times. I 
don't see where you refuted it, or even how you could via _a priori_ 
arguments. It's a real problem in multi-maintainer, large-world software 
networks.

/be

David Bruant wrote:
> That's not the conclusion I took from these discussions. As I feel 
> words are important, the conclusions I took are:
> WeakRefs are *necessary* for distributed acyclic garbage collection. 
> They are only *convenient* for observer patterns: people can always 
> unsubscribe their listeners or use another equivalent ".dispose() 
> protocol" (assuming the API has been thought with that in mind which 
> it is not always).

You seemed to concede my point from https://mail.mozilla.org/pipermail/es-discuss/2013-February/028572.html

---

> ... Real systems such as COM, XPCOM, Java, and C#
> support weak references for good reasons. One cannot do "data binding"
> transparently without either making a leak or requiring manual dispose
> (or polling hacks), precisely because the lifecycle of the model and
> view data are not known to one another, and should not be coupled.

> See http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs  intro, on
> the observer and publish-subscribe patterns.

---

and https://mail.mozilla.org/pipermail/es-discuss/2013-February/028575.html

---

> David Bruant wrote:
>>  A view knows own its lifecycle, it involves adding observers in a
>>  bunch of places. When the view lifecycle comes to an end for whatever
>>  reason, it only makes sense that it removes the observers it added.

> The problem is that the notification comes from a model object to the
> view via the observer. If the view holds the model object strongly, it
> can entrain the entire model. And if there is an association from model
> to view somewhere (which is not unreasonable, in a mostly self-hosted
> system), then....

with confirmation from Rafael Weinstein: https://mail.mozilla.org/pipermail/es-discuss/2013-March/028918.html

---

> This is exactly right.

---

In the large, there's no single controller who can manually dispose of 
everything and avoid leaks. This has been rediscovered many times. I 
don't see where you refuted it, or even how you could via _a priori_ 
arguments. It's a real problem in multi-maintainer, large-world software 
networks.