There are some fairly recent es-discuss threads about weak references. I don't know if there is a consensus yet (it is very hard to tell) but some people like Brendan are on record that there are real use cases that require them. I've been pushing hard for them, along with the author of embind. The question is mostly whether solving those problems is worth the cost of exposing GC to content JS (though, if memory serves, there was a claim in one of the discussion threads that you can implement weakrefs without exposing GC - I'm not sure if that was an 'I've figured it out' statement or just a hypothesis).
At present I don't believe WRs will ever make it onto the open web. It seems like there's a huge amount of resistance to the idea that is never going to go away, so any application that needs them is best-served by an emscripten-style heap and manually implemented collector (boehm, etc). You could probably achieve some sort of compromise by writing your own user-space collector that walks the reachable JS heap if you manage to root your JS objects correctly, but I suspect that would only be viable as a codegen strategy for a compiler targeting JS, not something you'd do by hand when writing JS. For some WR use cases you can probably do manual refcounting yourself, as long as you do it right - you'd want to replace the actual object references with a lightweight 'handle' object that forwards onto the real instance via a handle lookup, so that you can 'collect' the actual instance without requiring the handles to die. On Sun, Jul 6, 2014 at 3:17 AM, Till Schneidereit <t...@tillschneidereit.net> wrote: > There is an ES7 proposal for weak references[1] that would satisfy your > requirements. However, at least at Mozilla there is very strong opposition > to this from people working on the memory management subsystems (i.e. the GC > and CC). It's not clear to me that their arguments have been defeated and > I'm not aware of any more recent discussions about this topic than those on > Mozilla's platform development mailing list[2][3]. > > While I think that weak references are an important feature, I don't think > this particular use case is a good argument for them: in my personal > experience working with and implementing systems like you describe, weak > listeners were eventually deprecated and replaced by forced explicity > unsubscription every time. If a view is destroyed, you really don't want it > to receive any events anymore, regardless of the GC's timing. Now you could > say that in the framework's event dispatching or handling mechanism you can > detect this situation. If so, you can also just unsubscribe a strongly-held > event listener at that point. > > > [1]: http://wiki.ecmascript.org/doku.php?id=strawman:weakreferences > [2]: > https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/V__5zqll3zc > [3]: > https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/9LcqR9m5Mo4 > > > > On Sun, Jul 6, 2014 at 7:00 AM, Peter Michaux <petermich...@gmail.com> > wrote: >> >> Hi, >> >> I've been reading about WeakMap in the draft. To my surprise, it is >> not at all what I thought it would be or what I was hoping to use. At >> least that is my understanding. >> >> My use case is in MV* architectures. With current MV* frameworks, a >> model holds strong references to the views observing that model. If a >> view is removed from the DOM, all other references in the application >> are lost to that view, but the view never stopped observing the model >> object, that strong reference from model to view results in a zombie >> view. Avoiding this means views need to have `destroy` methods that >> unsubscribes the view from the model. It is easy for the application >> programmer to forget to call a view's `destroy` method and the >> application leaks memory. As a result of the leak, the user experience >> and ultimately the reputation of the Web suffers. If a model could >> hold weak references to its observers, this would safeguard against >> accidental and inevitable application programmer forgetfulness. >> >> It appears that WeakMap cannot help solve the current MV* zombie view >> problem. Or did I miss something? >> >> I was expecting WeakMap to hold its values weakly and set them to >> undefined or delete the associated key when the value was garbage >> collected. >> >> Does anything exist or is coming to help solve the zombie problem? >> >> ---- >> >> Smalltalk Squeak models use a WeakIdentityKeyDictionary which holds >> its keys weakly. The difference compared with the ECMAScript WeakMap >> is that instances of WeakIdentityKeyDictionary have an iterator so the >> observers can be stored as the keys and still discoverable without >> keeping other strong references. The ECMAScript standard specifically >> disallows in iterator. >> >> Thanks, >> Peter >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
