On 07/21/2011 01:56 AM, Jonas Sicking wrote:
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay<olli.pet...@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
