Weak event listener

Kevin Gadd kevin.gadd at gmail.com
Tue Mar 26 16:22:58 PDT 2013

OK, it seems like Weak References are now being discussed without the
context of previous discussions of weak references, which is a little
annoying. Non-contrived real-world use cases that require Weak References
(or a primitive with similar capabilities, like a Map with weak values
instead of weak keys, I'm not picky) have already been provided *on this
list* the last time WRs were discussed. I provided two based on real
applications I've worked on; I thought other people in the discussion
thread provided more.

What process needs to be followed before people will believe that Weak
References are a real primitive that solves real problems? Do you need a
set of broken, non-functional 'real world' applications written in JS that
work in a customized version of V8/SpiderMonkey that has WRs? Do you need
more verbose descriptions of use cases than previously provided? I can try
to provide more justification than I did previously if this is necessary; I
wasn't aware that it was.

I totally understand that security concerns and the limited number of hours
in the day have caused WRs to be postponed until ES7 or later (though this
makes me annoyed for obvious reasons), but if WRs as a useful feature are
somehow in such question that people are suggesting they are unnecessary, I
want to know how they got into this position and how to fix it.

The question of whether the non-determinism is justified is a hard one, of
course. Right now applications that need WRs aren't JS applications, so WRs
only pull their weight if it is worthwhile to have those applications
brought into the browser (instead of remaining in native execution
environments like NaCL or being emulated by a custom garbage collector
implementation inside of emscripten with typed arrays acting as a virtual

I can't answer the question of whether iterable WeakMaps are equivalent to
weak references. I do believe that with iterable WeakMaps you could
determine whether a given object has been collected, but I am having a hard
time imagining how one could performantly implement a Weak Reference via an
iterable WeakMap. The most obvious implementation would be to create a
single-key WeakMap for every Weak Reference, and treating the reference as
dead when the map contains 0 items. This would certainly 'work', but seems
like a rather roundabout way of solving the problem. With an iterable
WeakSet you'd at least be reducing the overhead, so that might be alright.
If this roundabout solution could get into ES6, then I suppose I would
probably prefer it to real WRs in ES<some larger digit>, because I prefer
solving customers' problems now to solving the problems of future customers


On Tue, Mar 26, 2013 at 1:03 PM, David Bruant <bruant.d at gmail.com> wrote:

> Le 26/03/2013 20:25, Jason Orendorff a écrit :
>  On Mon, Mar 25, 2013 at 9:29 PM, Erik Arvidsson
>> <erik.arvidsson at gmail.com> wrote:
>>> WeakMap would not work in this specific case since a WeakMap cannot be
>>> iteratered.
>> What would work here is determinism:
>>      https://gist.github.com/**jorendorff/5245857<https://gist.github.com/jorendorff/5245857>
>> For this, a deterministic API is just as easy to use, easier to
>> implement, and easier to reason about.
> I'm not entirely sure I understand your code snippet. Is withListener some
> equivalent of Node's once [1][2]?
> If so, then I agree, but, we're back to a debate earlier this month
> starting at [3] (implicitly forked).
> From the previous discussions, my understanding of the problem that
> weakrefs are expected to solve is automated cascading of GC, that is, a
> full subgraph gets collected as a result of releasing one reference
> assuming the convention that everyone with access to the weakref plays nice
> by always accessing the object via .get, and I guess via releasing the
> weakref (which is itself an object?) when useless.
> I'm still not entirely convinced whether the problem being solved is worth
> the non-determinism it brings along.
> I'm starting to wonder whether bringing weakrefs is equivalent to having
> iterable WeakMaps... And if so, why not make WeakMaps iterable?
>  The References section of the strawman is just a collection
>> of links to reactive libraries like Tangle[1], without elaboration.
>> But if Tangle actually used weak observer semantics, even the most
>> basic Tangle use cases would break! [2]
> The precedent of other languages was used as a justification of doing the
> same in JS and I guess this example is a good case of why this might not be
> a good argument. In JS, listeners are functions which are their own objects
> and keeping one hard reference imposes a different constraint than in other
> languages.
> David
> [1] http://nodejs.org/api/events.**html#events_emitter_once_**
> event_listener<http://nodejs.org/api/events.html#events_emitter_once_event_listener>
> [2] https://github.com/joyent/**node/blob/**2eb847849fc133e39d64798bee0125
> **2d9f3c4b58/lib/events.js#L169-**L182<https://github.com/joyent/node/blob/2eb847849fc133e39d64798bee01252d9f3c4b58/lib/events.js#L169-L182>
> (the implementation is clean enough to be a good documentation in itself,
> kudos to the Node folks :-) )
> [3] https://mail.mozilla.org/**pipermail/es-discuss/2013-**
> March/028921.html<https://mail.mozilla.org/pipermail/es-discuss/2013-March/028921.html>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130326/6245931d/attachment.html>

More information about the es-discuss mailing list