Weak event listener

David Bruant bruant.d at gmail.com
Tue Mar 26 13:03:30 PDT 2013

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
> 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.


[1] http://nodejs.org/api/events.html#events_emitter_once_event_listener
(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

More information about the es-discuss mailing list