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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
