W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [UndoManager] Re-introduce DOMTransaction interface?

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 05 Jul 2012 17:36:59 +0300
Message-ID: <4FF5A68B.1030903@helsinki.fi>
To: Adam Barth <w3c@adambarth.com>
CC: Ryosuke Niwa <rniwa@webkit.org>, public-webapps <public-webapps@w3.org>, Ojan Vafai <ojan@chromium.org>, Jonas Sicking <jonas@sicking.cc>, Ehsan Akhgari <ehsan@mozilla.com>, Erik Arvidsson <arv@chromium.org>, Sukolsak Sakshuwong <sukolsak@gmail.com>, Aryeh Gregor <ayg@aryeh.name>
On 07/05/2012 05:15 PM, Adam Barth wrote:
> On Thu, Jul 5, 2012 at 1:37 AM, Olli Pettay <Olli.Pettay@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.Pettay@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.

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 <Olli.Pettay@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.
>
> Adam
>
Received on Thursday, 5 July 2012 14:37:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:53 GMT