What is the status of Weak References?
bruant.d at gmail.com
Sat Feb 2 05:19:51 PST 2013
Le 02/02/2013 06:41, Nathan Wall a écrit :
> 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
> the `setInterval` keeps it alive in memory even after the developer
> using the library has long since discarded it.
Since we're discussing the addition of a new feature, let's first start
to see how existing or about-to-exist features can help us solve the
In an ES6 world, new Widget() can return a proxy and you, as the widget
library author, can track down anytime the element is moved and resized
(the handler will probably have to do some unwrapping, function binding,
etc, but that's doable).
DOM mutation observers  can be of some help to track down this, I think.
Hmm... It's been a couple of years that I have the intuition that events
should be considered as part of an object interface and not some sort of
external thing and I think the justification is right here.
Doing setInterval polling has you do forces you to create a function
unrelated to the object you want to observe and keeps a reference in
If you were able to attach an event listener to the object itself to be
notified of just what you need, the observer function would die as soon
as the object it's attached to would die.
In your particular case, events at the object level would solve your
problem, I think.
> nor did we want to impose `dispose` (it's an easy thing to forget to
I'd like to repeat something I wrote in another message: "...a very
important point that most developers ignore or forget. GC is an
undecidable problem, meaning that there will always be cases where a
human being needs to figure out when in the object lifecycle it is not
longer needed and either free it in languages where that's possible or
make it collectable in languages with a GC. There will be such cases
even in languages where there are weak references. "
And when such a case will be found, what will be the solution? Adding a
new subtler language construct which exposes a bit more of the GC?
a web page lives for a couple of minutes; leaks were largely
unnoticeable because navigating or closing a tab would make the content
collectable (well... except in crappy version of IE in which JS content
could make browser-wide leaks -_-#).
about our memory usage, we have to question what we assumed/knew of
code, but we must never forget that the GC only does an approximation of
an undecidable problem.
In applications where memory matters a lot, maybe a protocol like
.dispose will become necessary.
> 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.
Do you mean events? :-)
> Having said that, I also understand the desire to keep the language
> deterministic and to not expose GC operations.
About weakrefs, I've read a little bit  and I'm puzzled by one
thing: the return value of get is a strong reference, so if a
misbehaving component keeps this strong reference around, having passed
a weak reference was pointless.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss