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 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:37 UTC