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 <petermichaux at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140706/dad40c8c/attachment.html>

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

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