Le 28/07/2013 03:15, Brendan Eich a écrit :
David Bruant wrote:
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.
We're going in circles. From
https://mail.mozilla.org/pipermail/es-discuss/2013-February/028575.html
"""
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....
"""
This was the message I was looking for when I first replied --
apologies for not finding it in time. You didn't reply directly.
I feel I can't reply as I don't have enough information. Who created
(and more generally is in charge of the lifecycle of) the model object?
the view? the observer?
My impression is that the answer can't be found only within the scope of
these 3 objects but has to be found at a higher-level (level of whoever
created them and/or manipulates them).
In essence, make me a complete list of who created who, who holds a
reference to who (and there are necessarily other objects than the 3
cited) and I'll tell you who should be doing what when.
I intuit (no formal proof) that any combination will have a solution
where the memory can be manually dispose. I don't guarantee the solution
will be simple to express in code :-) I also don't guarantee it will be
as easy as with WeakRefs. But I feel it's possible.
"Convenience" sounds like some pampering measure that real programmers
can do without.
I feel you're over-reacting on the word "convenience" (or maybe I've
been misusing it?). There are lots of things I consider "conveniences"
in ES6 like const, arrow functions or Array.prototype.find. It doesn't
mean I don't want them in the language; quite the opposite. But I know
people can do without these (and they sure have for a long time)
And don't put "real programmers" in my mouth unless it's to talk about
butterflies http://xkcd.com/378/ :-) That really isn't something I would
say or even think.
I don't think this is a fair assessment. Let's ask Yehuda, because
Ember.js would benefit from weakrefs, and its API without them is
harder to use and leak-prone.
But let's also assume your words are fair. You still conceded weakrefs
are needed for distributed systems per Mark's original strawman.
That's indisputable. So how are we going to avoid adding them to ES7
by calling them a convenience for other cases if they're required for
the full distributed ocap case?
I didn't say I wanted them out (not on this thread and not anymore). I
feel there is a mismatch between what I mean by "convenience" and what
you understand.
I've gone through different phases about WeakRefs.
I initially (time of the messages you quote) didn't understand the need.
The discussions made me understand that one use case they cover is a
language-level "finalizer mechanism". I disagreed with this use case by
saying that people could also better design their APIs.
Mark Miller then brought up the distributed acyclic GC use case [1]
which, at first, was way beyond my understanding. After a discussion
with Mark, he explained to me the link he had posted on es-discuss and
it was clear that there was no other way than adding WeakRefs to the
language [2].
Concurrently, after some maturation on the difference between a manual
".dispose() protocol" and WeakRefs it has become clear to me why and how
they're convenient and I've come to not be too reluctant about them
anymore even for this use case.
With all that said, as far as data binding or other "finalizer" use
cases, WeakRefs remain a convenience (which to me means: "it's possible
to do without"). As a convenience (and exactly like for class syntax or
arrow function or Number.isNaN), it is important for authors to know
what WeakRefs are convenient for, but also what problems they don't
solve. I guess it's the same for classes. They are convenient to model
some sorts of object models, but would be misused in some circumstances.
I feel that describing WeakRefs as *necessary* (for finalizer use cases)
sends the wrong message. Easily misinterpretable as "we had leaks
because we didn't have WeakRefs" while this is never true, I believe
(within one memory space).
You'll certainly agree that it'd be unfortunate if a word got
misinterpreted ;-)
David
[1] http://erights.org/elib/distrib/captp/4tables.html
[2] well... actually there is, but it involves putting in the language a
protocol like CapTP and that would not be desirable. That would probably
be a lot of work for TC39 just to agree on the exact protocol. And
forcing one particular protocol doesn't sound like a good idea. Imagine
if someone comes along with another better protocol... WeakRefs empower
JS devs to experiment all sorts of protocols. So WeakRefs are necessary
at least for that reason.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
