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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
