On Sun, Jul 6, 2014 at 7:47 AM, Katelyn Gadd <k...@luminance.org> wrote:
> 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). > I would be very curious. It seems impossible by definition. Could you (or anyone) please try to find this? Thanks. What I have claimed is that we can isolate the communications channel that this provides in ways that make it a reasonable (IMO) security risk. Perhaps this is what you are thinking of? > > 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 > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
