Re: Mutation events replacement

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