And by fail I mean result in a set of objects that next gets collected by the GC correctly despite being otherwise fit to be collected.
On Fri, Feb 1, 2013 at 10:12 AM, Brandon Benvie <bran...@brandonbenvie.com>wrote: > Indeed, and Continuum uses the same strategy for implementing WeakMap > currently. To my knowledge, the circumstances that makes that > implementation of WeakMap fail is unlikely to arise except in the case of a > membrane. As a polyfill provided to developers devloping with ES5 as a > target, this is acceptable since a membrane requires an implementation of > Proxy. But since Continuum implements Proxy, this sets up the one case > where the two (lack of native WeakMaps and Proxy) to meet. > > > On Fri, Feb 1, 2013 at 10:07 AM, David Bruant <bruan...@gmail.com> wrote: > >> Le 01/02/2013 15:53, Brandon Benvie a écrit : >> >> It's not possible to polyfill or emulate weak references (or WeakMaps >>> for that matter) in JS without completely disengaging from using the host >>> JS engine's object model. >>> >> For all practical purposes, you've done such a thing yourself >> https://github.com/Benvie/**WeakMap <https://github.com/Benvie/WeakMap>;-) >> >> >> In Continuum, for example, I can get close but not quite all the way to >>> emulating WeakMaps using a meta-interpretive approach to the object model >>> (each object in the VM corresponds to one or more objects in the host >>> engine). Eventually I'll switch to switching to using my own >>> typedarray-backed heap with a GC in order to fully realize the semantics of >>> WeakMaps. >>> >> There are probably minor limitations to your above implementation, but I >> wonder if they're worth the trouble to move to a typedarray heap. It's your >> call not mine anyway :-) >> >> David >> > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
