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.

Le 28/07/2013 03:15, Brendan Eich a écrit :
> 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.

> 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 ;-)

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