What is the status of Weak References?

David Bruant bruant.d at gmail.com
Sat Mar 2 02:58:07 PST 2013

Le 02/03/2013 01:58, Rafael Weinstein a écrit :
> On Sat, Feb 2, 2013 at 11:02 AM, Brendan Eich <brendan at mozilla.com> wrote:
>> David Bruant wrote:
>>> Interestingly, revocable proxies require their creator to think to the
>>> lifecycle of the object to the point where they know when the object
>>> shouldn't be used anymore by whoever they shared the proxy with. I feel this
>>> is the exact same reflections that is needed to understand when an object
>>> isn't needed anymore within a trust boundary... seriously questioning the
>>> need for weak references.
>> Sorry, but this is naive. Real systems such as COM, XPCOM, Java, and C#
>> support weak references for good reasons. One cannot do "data binding"
>> transparently without either making a leak or requiring manual dispose (or
>> polling hacks), precisely because the lifecycle of the model and view data
>> are not known to one another, and should not be coupled.
>> See http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs intro, on the
>> observer and publish-subscribe patterns.
> This is exactly right.
> I'm preparing an implementation report on Object.observe for the next
> meeting, and in it I'll include findings from producing a general
> purpose observation library which uses Object.observe as a primitive
> and exposes the kind of semantics that databinding patterns are likely
> to need.
> Without WeakRefs, observation will require a dispose() step in order
> to allow garbage collection of observed objects, which is (obviously)
> very far from ideal.
There is another approach taken by the requestAnimationFrame API that 
consists in one-time event listeners (Node.js also has that concept too 
[1]), requiring to re-subscribe if one wants to listen more than once.
I wonder why this approach has been taken for requestAnimationFrame 
which is fired relatively often (60 times a second). I'll ask on 
I won't say it's absolutely better than WeakRefs and it may not apply to 
the data binding case (?), but it's an interesting pattern to keep in mind.

I'm looking forward to reading your findings in the meeting notes.


[1] http://nodejs.org/api/events.html#events_emitter_once_event_listener

More information about the es-discuss mailing list