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

Re: Mutation events replacement

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 21 Jul 2011 12:39:11 +0300
Message-ID: <4E27F3BF.3050301@helsinki.fi>
To: Jonas Sicking <jonas@sicking.cc>
CC: public-webapps@w3.org
On 07/21/2011 01:56 AM, Jonas Sicking wrote:
> On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay<Olli.Pettay@helsinki.fi>  wrote:
>> On 07/20/2011 06:46 PM, Jonas Sicking wrote:
>>>>> Hence I'm leaning towards using the almost-asynchronous proposal for
>>>>> now. If we end up getting the feedback from people that use mutation
>>>>> events today that they won't be able to solve the same use cases, then
>>>>> we can consider using the synchronous notifications. However I think
>>>>> that it would be beneficial to try to go almost-async for now.
>>>> I disagree.
>>> I had hoped for a bit more of an explanation than that ;-)
>>> Such as why do you not think that synchronous events will be a problem
>>> for web developers just like they have been for us?
>> In practice synchronous events have been a problem to us because we
>> are in C++, which is unsafe language. Web devs use JS.
> The only C++ specific problem that we've had is dangling pointers.
> However only a small set of our problems would have been solved by
> making local points strong.

"only a small set of our problems" is a major understatement. Huge
number of problems have been fixed using either strong references or
things like nsWeakFrame (the original reason for nsWeakFrame was
to fix a class of bugs related to dangling pointers which were caused by
mutation event listeners doing something unexpected).

> We'd still have problems with indexes changing under us, and nodes
> that we removed from one location now being inserted elsewhere, etc.
> Another way to look at it is that due to C++ specific problems, when
> unexpected things happen during callbacks, we end up possibly
> crashing. In Javascript, if unexpected things happen during callbacks,
> you'll get buggy behavior. That's better, but still not good.
>> Web devs usually want something synchronous, like sync XHR
>> (sync XHR has other problems not related to mutation handling).
>> Synchronous is easier to understand.
> That is a wholly different type of sync API. Those are APIs where the
> return value is delivered through a callback rather than as a return
> value, forcing you to create awkward code like:
> doSomething(function(res1) {
>    res1.callFunc(function(res2) {
>      doSomethingElse(res2);
>    }
> }
> There's a very good problem description here: http://tamejs.org/
> (ignore the proposed solution, it's the problem description that's
> interesting for this discussion).
Reading... will comment later.

> Those problems aren't happening here as far as I can tell. There are
> no return values delivered asynchronously, nor any of the problems
> described in the tamejs page.
> / Jonas
Received on Thursday, 21 July 2011 09:39:51 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:34 UTC