On Thu, Jul 5, 2012 at 1:37 AM, Olli Pettay <[email protected]> wrote: > On 07/05/2012 08:00 AM, Adam Barth wrote: >> On Wed, Jul 4, 2012 at 5:25 PM, Olli Pettay <[email protected]> >> wrote: >>> On 07/05/2012 03:11 AM, Ryosuke Niwa wrote: >>> So, it is very much implementation detail. >>> >>> (And I still don't understand how a callback can be so hard in this case. >>> There are plenty of different kinds of callback objects. >>> new MutationObserver(some_callback_function_object) ) >> >> I haven't tested, by my reading of the MutationObserver implementation >> in WebKit is that it leaks. Specifically: >> >> MutationObserver --retains--> MutationCallback --retains--> >> some_callback_function_object --retains--> MutationObserver >> >> I don't see any code that breaks this cycle. > > Ok. In Gecko cycle collector breaks the cycle. But very much an > implementation detail. > >> DOM events > > Probably EventListeners, not Events. > >> have a bunch of delicate code to avoid break these >> reference cycles and avoid leaks. We can re-invent that wheel here, > > Or use some generic approach to fix such leaks. > >> but it's going to be buggy and leaky. > > In certain kinds of implementations. > >> I appreciatie that these jQuery-style APIs are fashionable at the >> moment, but API fashions come and go. If we use this approach, we'll >> need to maintain this buggy, leaky code forever. > > Implementation detail. Very much so :)
Right, my point is that this style of API is difficult to implement correctly, which means authors will end up suffering low-quality implementations for a long time. On Thu, Jul 5, 2012 at 2:22 AM, Olli Pettay <[email protected]> wrote: > But anyhow, event based API is ok to me. > In general I prefer events/event listeners over other callbacks. Great. I'd recommend going with that approach because it will let us provide authors with high-quality implementations of the spec much sooner. Adam
