On 07/05/2012 05:15 PM, Adam Barth wrote:
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.
My point is that it is not too difficult to implement such API correctly,
it just happens to be difficult currently in one(?) implementation.
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
