On 07/05/2012 08:01 PM, Ojan Vafai wrote:
On Thu, Jul 5, 2012 at 7:15 AM, Adam Barth <w...@adambarth.com
<mailto:w...@adambarth.com>> wrote:
On Thu, Jul 5, 2012 at 1:37 AM, Olli Pettay <olli.pet...@helsinki.fi
<mailto:olli.pet...@helsinki.fi>> wrote:
> On 07/05/2012 08:00 AM, Adam Barth wrote:
>> On Wed, Jul 4, 2012 at 5:25 PM, Olli Pettay <olli.pet...@helsinki.fi
<mailto:olli.pet...@helsinki.fi>>
>> 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 <olli.pet...@helsinki.fi
<mailto:olli.pet...@helsinki.fi>> 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.
The downside of events is that they have a higher overhead than we originally
thought was acceptable for mutation events (e.g. just computing the
ancestor chain is too expensive). Now that we fire less frequently, the
overhead might be OK, but it's still not great IMO.
Only having a high-overhead option for any new APIs we add is problematic. I
appreciate the implementation complexity concern, but I think we just
need to make callbacks work.
We could fire the event on the MutationObserver itself. That would be
lightweight. That doesn't help though, right?
new MutationObserver().addEventListener('onMutation', function() {}) vs. new
MutationObserver().observe(function() {})
MutationObserver ctor takes the callback, not observe().
We're certainly not going to change MutationObserver callback handling.
MutationObserver is already unprefixed and all.
And in MutationObserver case having just one callback object per observer keeps
things easier.
In many other cases the possibility for many callbacks (eventlisteners) is
preferred.
But about UndoManager, I'd like to see the proposal how to handle transactions
using events.
-Olli