Weak event listener
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
> What would work here is determinism:
> 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 ?
If so, then I agree, but, we're back to a debate earlier this month
starting at  (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, without elaboration.
> But if Tangle actually used weak observer semantics, even the most
> basic Tangle use cases would break! 
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.
(the implementation is clean enough to be a good documentation in
itself, kudos to the Node folks :-) )
More information about the es-discuss