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.

"Convenience" sounds like some pampering measure that real programmers 
can do without. 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?

/be

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.

"Convenience" sounds like some pampering measure that real programmers 
can do without. 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?