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