David Bruant wrote:> >> David Bruant wrote: > >> Garbage collectors have evolved and cycles aren't an issue any longer, weak > >> references or not.> >> > Kevin Gadd wrote: > > Cycles are absolutely an issue, specifically because JS applications > > can interact with systems that are not wholly managed by the garbage > > collector. The problem in this case is a cycle being broken *too > > early* because the application author has to manually break cycles. To > > present a couple simple examples: > > > > I have a top-level application object that manages lower-level 'mode' > > objects representing screens in the application. The screens, when > > constructed, attach event listeners to the application object. Because > > the application manages modes, it needs to have a list of all the > > active modes. > > * The event handler closures can accidentally (or intentionally)>> Last I > > heard, it's very difficult to accidentally capture a reference in > a closure because modern engines check which objects are actually used > (looking at variable names), so for an object to be captured in a > closure, it has to be used. So "intentionally".
We had a situation recently where we needed to monitor an element with `setInterval` to get information about when it was resized or moved. As library authors we wanted to encapsulate this logic into the module so that it would "just work". We wanted someone to be able to call `var widget = new Widget();`, attach it to the document, and have it automatically size itself based on certain criteria. If a developer then moved its position in the document (using purely DOM means), we wanted it to resize itself automatically again. We didn't want to make a requirement to call a public `resize` method, nor did we want to impose `dispose` (it's an easy thing to forget to call and it doesn't feel like JavaScript). Of course, strongly referencing the element in the `setInterval` keeps it alive in memory even after the developer using the library has long since discarded it. In this case, we managed to come up with a solution to refer to elements "weakly" through selectors, retrieving them out of the document only when they're attached (we have a single `setInterval` that always runs, but it allows objects to be GC'd). However, this solution is far from fool-proof, lacks integrity (any element can mimic our selectors and cause us grief), and not performant. In our case it's good enough, but I can imagine a case where it wouldn't be. I can also imagine a case where you wouldn't have the luxury to use DOM traversal as a "weak" mechanism for referring to objects. I think it could be useful internally in library components which make use of 3rd party components (in this case the DOM) to be able to monitor aspects of those components only when they're being consumed. Having said that, I also understand the desire to keep the language deterministic and to not expose GC operations. Nathan
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
