What is the status of Weak References?

[David Bruant]

Le 02/03/2013 12:11, Kevin Gadd a écrit :
> 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.
It's not really about "periodic", but rather about the idea of a "one 
time listener". The reason I talked about 60 frames per second is that 
it's an event that's fired very often, so it may have a significant cost 
something at runtime to conditionally re-register.

The general problem is to know when someone listening actually wants to 
stop listening. Currently, the default of observing is "observe ad vitam 
æternam" which obviously causes the issue of "what if actually it's been 
long that we didn't want to observe?"
The "one time listener" approach is interesting, because it doesn't say 
"observe ad vitam æternam", but rather "I'll call you only once, figure 
out the rest on your own" (so, re-subscribe if that's what you want).
On the huge benefits of this approach, the problem of GC-ing observers 
is completely solved by the API. Well, not exactly. Maybe you 
registered, but don't care before the event happens, so your observer is 
garbage until called once. But after the event happens, it can be released.

In a way, a one-time listener can be seen as an auto-wrapped (wrapped by 
the event emitter, not the one who registered it) one-time reference 
(very weak reference?).

> If anything, requestAnimationFrame is an example of an API that poorly
> expresses developer intent.
I've asked [1], we'll see. I'm not very interested in rAF specifically, 
because I mostly agree with you that from all the code snippets I've 
read and written, people re-subscribe unconditionally. Maybe some more 
complex applications don't.

> 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
The lifetime management *is* on the application developer shoulders. It 
always has and will always be. GC and weakrefs are just conveniences to 
make this work (much!) easier. There are cases where a GC isn't 
sufficient. There will always be cases where manual disposal will be 
necessary. Even if the language gets WeakRefs.
When a developer wraps an object in a WeakRef before handing it to 
observe an event, the developer is making a lifetime management decision.

> 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.
I feel misintrepreted. There is a long way from my
"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."
and your intrepretation of my post.
I shared an idea that hadn't been shared yet on this thread. I didn't 
say it would solve all problems. I've actually been careful to say that 
it may not.

David

[1] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0623.html