Weak event listener

Marius Gundersen gundersen at gmail.com
Tue Mar 26 04:09:28 PDT 2013


So to summarize:

- This would be very useful in large MVC applications with many independent
components.
- Even with WeakMaps there is no way to implement weak event listeners,
since WeakMaps cannot be iterated. A weak reference implementation would
solve this.
- The main problem with weak event listeners is that they are not
deterministic; even if you remove all references to an object there is no
way to ensure that the object is garbage collected immediately, and so
events would still be dispatched to it for an indeterminable period of time
after the last strong reference is severed. I'm not sure of how big of a
problem this would be; it might be an annoyance or it might break the
application completely.

Marius Gundersen


On Tue, Mar 26, 2013 at 4:24 AM, Benoit Marchant <marchant at mac.com> wrote:

> Very true, I'm wondering if based on usage today it could make sense to
> have this as default behavior on current API?
>
> Benoit
>
> On Mar 25, 2013, at 19:51, Peter Michaux <petermichaux at gmail.com> wrote:
>
> > On Mon, Mar 25, 2013 at 2:55 AM, Marius Gundersen <gundersen at gmail.com>
> wrote:
> >
> >> One thing which is impossible to make in JavaScript today is a weakly
> >> referenced event listener system. In such a system an event listener is
> not
> >> strongly referenced by the event system, so events are only dispatched
> to it
> >> as long as another object holds a reference to it.
> >
> > Being able to make an observable subject that keeps a weak list of
> > observers would be very useful to ease memory management within an
> > application and avoid accidental memory leaks at the application
> > level. Sometimes the application programmer may forgot to remove a
> > observer from an observable subject, for example.
> >
> > With regard to the MVC architecture, this could be the best addition
> > to the language to make application development easier. A view might
> > mistakenly not unsubscribe from its associate model when the view is
> > destroyed, for example. That or the view's destroy method is never
> > even called because the application programmer forgot to call it.
> >
> > 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/20130326/4906806a/attachment.html>


More information about the es-discuss mailing list