There is an ES7 proposal for weak references[1] that would satisfy your requirements. However, at least at Mozilla there is very strong opposition to this from people working on the memory management subsystems (i.e. the GC and CC). It's not clear to me that their arguments have been defeated and I'm not aware of any more recent discussions about this topic than those on Mozilla's platform development mailing list[2][3].
While I think that weak references are an important feature, I don't think this particular use case is a good argument for them: in my personal experience working with and implementing systems like you describe, weak listeners were eventually deprecated and replaced by forced explicity unsubscription every time. If a view is destroyed, you really don't want it to receive any events anymore, regardless of the GC's timing. Now you could say that in the framework's event dispatching or handling mechanism you can detect this situation. If so, you can also just unsubscribe a strongly-held event listener at that point. [1]: http://wiki.ecmascript.org/doku.php?id=strawman:weakreferences [2]: https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/V__5zqll3zc [3]: https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/9LcqR9m5Mo4 On Sun, Jul 6, 2014 at 7:00 AM, Peter Michaux <petermich...@gmail.com> wrote: > Hi, > > I've been reading about WeakMap in the draft. To my surprise, it is > not at all what I thought it would be or what I was hoping to use. At > least that is my understanding. > > My use case is in MV* architectures. With current MV* frameworks, a > model holds strong references to the views observing that model. If a > view is removed from the DOM, all other references in the application > are lost to that view, but the view never stopped observing the model > object, that strong reference from model to view results in a zombie > view. Avoiding this means views need to have `destroy` methods that > unsubscribes the view from the model. It is easy for the application > programmer to forget to call a view's `destroy` method and the > application leaks memory. As a result of the leak, the user experience > and ultimately the reputation of the Web suffers. If a model could > hold weak references to its observers, this would safeguard against > accidental and inevitable application programmer forgetfulness. > > It appears that WeakMap cannot help solve the current MV* zombie view > problem. Or did I miss something? > > I was expecting WeakMap to hold its values weakly and set them to > undefined or delete the associated key when the value was garbage > collected. > > Does anything exist or is coming to help solve the zombie problem? > > ---- > > Smalltalk Squeak models use a WeakIdentityKeyDictionary which holds > its keys weakly. The difference compared with the ECMAScript WeakMap > is that instances of WeakIdentityKeyDictionary have an iterator so the > observers can be stored as the keys and still discoverable without > keeping other strong references. The ECMAScript standard specifically > disallows in iterator. > > Thanks, > Peter > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
