Weak event listener

Mark S. Miller erights at google.com
Tue Mar 26 17:22:55 PDT 2013

On Tue, Mar 26, 2013 at 11:22 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:

> 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
> heap).
> 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,

It can't, because it raises all the hard issues raised by weak-refs. We are
not going to add issues this deep to ES6 at this date. We've already
postponed easier issues to ES7.

> 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 later.
> Thanks,
> -kg
> 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>
> --
> -kg
> _______________________________________________
> 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/20130327/c2126f95/attachment.html>

More information about the es-discuss mailing list