On Tue, Mar 26, 2013 at 11:22 PM, Kevin Gadd <[email protected]> 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 <[email protected]> wrote: > >> Le 26/03/2013 20:25, Jason Orendorff a écrit : >> >> On Mon, Mar 25, 2013 at 9:29 PM, Erik Arvidsson >>> <[email protected]> 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 >> [email protected] >> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >> > > > > -- > -kg > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
