What is the status of Weak References?

Kevin Gadd kevin.gadd at gmail.com
Sat Mar 2 03:11:55 PST 2013

I don't understand how the requestAnimationFrame approach (to
registering periodic callbacks) applies to scenarios where you want
Weak References (for lifetime management) or to observe an object (for
notifications in response to actions by other arbitrary code that has
a reference to an object). These seem to be significantly different
problems with different constraints.

If anything, requestAnimationFrame is an example of an API that poorly
expresses developer intent. It is rare for someone to actually only
ever want to render a single animation frame; furthermore most
animation scenarios in fact require rendering a series of frames on
consistent timing. Furthermore, the need to manually trigger further
frame callbacks is error-prone - you are essentially offloading the
cost of lifetime management onto the application developer, by making
them manually manage the lifetime of their callback on an ongoing
basis by having to remember to say 'please keep my animation alive' at
the right time every frame no matter what, which probably means a try
block and auditing their rAF callback to ensure that all exit paths
call rAF again. I suspect that if you were to look at most
applications that use rAF, you would find very few of them
intentionally stop running animation frames in any scenario other than
the termination of the application. For this and other reasons, I
would suggest that it is a horrible idea to use rAF as an example of
how to design an API or solve developer problems - especially problems
as important as those addressed by weak references.


On Sat, Mar 2, 2013 at 2:58 AM, David Bruant <bruant.d at gmail.com> wrote:
> 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 public-webapps.
> 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.
> David
> [1] http://nodejs.org/api/events.html#events_emitter_once_event_listener
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list