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, 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 <bruan...@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.arvids...@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@mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -- -kg
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
