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. -kg On Sat, Mar 2, 2013 at 2:58 AM, David Bruant <bruan...@gmail.com> wrote: > Le 02/03/2013 01:58, Rafael Weinstein a écrit : >> >> On Sat, Feb 2, 2013 at 11:02 AM, Brendan Eich <bren...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
