Le 28/07/2013 01:11, Brendan Eich a écrit :
> with confirmation from Rafael Weinstein:
>
> https://mail.mozilla.org/pipermail/es-discuss/2013-March/028918.html
>
> "This is exactly right."
let's quote a bit more from the same message:

"Without WeakRefs, observation will require a dispose() step in order
to allow garbage collection of observed objects, which is (obviously)
very far from ideal."

And this is exactly what I meant by "convenience"; nothing more, nothing 
less. It's possible to do non-leaky observation without WeakRefs if the 
APIs of the objects involved take object disposal into account when 
designing their APIs, but it's just annoying (my interpretation of "very 
far from ideal")

> In the large, there's no single controller who can manaully dispose of 
> everything and avoid leaks.
I never said or suggested that such a thing was needed. Where does this 
idea come from? There is no need for a "master controller" (which 
doesn't sound very OCap-friendly anyway)
Each view and each model has some other object (maybe another view or 
model or maybe some other object) that created it and bound it 
respectively to a model or a view (or several). This creator/binder 
(doesn't need to be unique for all objects and most likely isn't) takes 
care of the model or view object lifecycle it's "responsible for" and 
can unbind when it becomes necessary in the object lifecycle.
Or can dispose of the view/model data-bound pair at once without even 
needing to unlisten since they have each other's listener.


> This has been rediscovered many times.
Did they try fine-grained lifecycle management? :-)
If the first idea for large-scale software is a single master 
controller, I can imagine why it doesn't work.
WeakRefs offer fine-grain distribution of control of who's holding a 
reference to whom and that solves the problem a single master controller 
CPOF.
A .dispose convention backed by API so that whoever bound 2 objects 
unbinds them when one becomes unnecessary is another form of fine-grain 
distribution.
To be honest, both are pretty much the same thing. The only difference 
is that in one case the developer triggers the cascade of disposal, in 
another case GC does it.
Granted, GC-triggering is more convenient. It may also be more easily 
accepted to have the convention at the language level than at the 
developer level.

> 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.
As I said WeakRefs are a convenience. I don't mean that negatively. A 
convenience pays off at large-scale.

> You seemed to concede my point from
>
> https://mail.mozilla.org/pipermail/es-discuss/2013-February/028572.html
>
> and
>
> https://mail.mozilla.org/pipermail/es-discuss/2013-February/028575.html 
I didn't answer as I didn't find a proper answer at the time.
But my answer is above. For each view and model some other object takes 
care of the lifecycle. These "some other objects" (plural) are who can 
decide of the unbinding when necessary. If one of this "other object" is 
responsible for an otherwise independent model/view pair, it can throw 
them away, not even a need to unbind.

David

Le 28/07/2013 01:11, Brendan Eich a écrit :
> with confirmation from Rafael Weinstein https://mail.mozilla.org/pipermail/es-discuss/2013-March/028918.html
>
> ---
>
>> This is exactly right.
>
> ---

let's quote a bit more from the same message:

---

> Without WeakRefs, observation will require a dispose() step in order to allow garbage collection of observed objects, which is (obviously) very far from ideal.

---

And this is exactly what I meant by "convenience"; nothing more, nothing 
less. It's possible to do non-leaky observation without WeakRefs if the 
APIs of the objects involved take object disposal into account when 
designing their APIs, but it's just annoying (my interpretation of "very 
far from ideal")

> In the large, there's no single controller who can manually dispose of 
> everything and avoid leaks.

I never said or suggested that such a thing was needed. Where does this 
idea come from? There is no need for a "master controller" (which 
doesn't sound very OCap-friendly anyway)
Each view and each model has some other object (maybe another view or 
model or maybe some other object) that created it and bound it 
respectively to a model or a view (or several). This creator/binder 
(doesn't need to be unique for all objects and most likely isn't) takes 
care of the model or view object lifecycle it's "responsible for" and 
can unbind when it becomes necessary in the object lifecycle.
Or can dispose of the view/model data-bound pair at once without even 
needing to unlisten since they have each other's listener.


> This has been rediscovered many times.

Did they try fine-grained lifecycle management? :-)
If the first idea for large-scale software is a single master 
controller, I can imagine why it doesn't work.
WeakRefs offer fine-grain distribution of control of who's holding a 
reference to whom and that solves the problem a single master controller 
CPOF.
A .dispose convention backed by API so that whoever bound 2 objects 
unbinds them when one becomes unnecessary is another form of fine-grain 
distribution.
To be honest, both are pretty much the same thing. The only difference 
is that in one case the developer triggers the cascade of disposal, in 
another case GC does it.
Granted, GC-triggering is more convenient. It may also be more easily 
accepted to have the convention at the language level than at the 
developer level.

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

As I said WeakRefs are a convenience. I don't mean that negatively. A 
convenience pays off at large-scale.

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

I didn't answer as I didn't find a proper answer at the time.
But my answer is above. For each view and model some other object takes 
care of the lifecycle. These "some other objects" (plural) are who can 
decide of the unbinding when necessary. If one of this "other object" is 
responsible for an otherwise independent model/view pair, it can throw 
them away, not even a need to unbind.