Experimental implementation of Object.observe & JS Utility library now available

John J Barton johnjbarton at johnjbarton.com
Sun Aug 19 11:25:29 PDT 2012

On Fri, Aug 17, 2012 at 9:49 PM, Rafael Weinstein <rafaelw at chromium.org>wrote:

> >> A synchronous observation mechanism provides an attacker too many
> >> opportunities for a plan interference attack. If you'll recall, an
> earlier
> >> synchronous proposal died for this reason.
> That is an excellent reason. I have two others:
> 1) It's a terrible design pattern to encourage. Webdevs will
> absolutely use it and learn the hard way, just like we did with
> Mutation Events that it works fine when we start, but down the road
> lies nothing but pain and suffering.
> 2) Synchronous doesn't actually exist -- it's a false option.
> To explain: When people talk about "synchronous" what they expect is
> that they will be notified concurrent with the event happening (this
> *is happening*). The expectation is that when they are invoked they
> are observing the world as the event is describing.
> This is the appeal of synchronous delivery. Here's the rub: unless you
> plan to only allow a single observer per object, then you have to pick
> someone to go first. And unless you plan to prevent that person from
> further mutating the object, the next guy to be called may not observe
> the world in the state suggested by the "synchronous" call.
> In fact, an arbitrary number of mutations can always have occurred by
> the time any given observer is called, so it's just dishonest API
> which pretends that a single thing has happened. The correct thing is
> to inform each observer what *set* of things has happened.
> So the only questions are:
> 1) Do you mislead the consumer with API which suggests that only one
> thing will has happened
> 2) If not, when do you deliver the set of things: immediately after
> the mutation occurs, at the end of the turn or ask the UA to schedule
> a future task.
> Referring back to my reason (1) This question was debated extensively
> with DOM Mutation Observers and unanimously decided that the end of
> the turn was the only good solution. "immediately" puts all code in
> danger of having its runtime assumptions invalidated after every
> operation which mutates objects and "future task" is far too late to
> be useful for most almost all use cases.

I can understand how batched changes and end-of-turn asynchronous calls are
 a good match.  The development model is now "here are the changes from
this turn" rather than "here is a change".

But I don't understand how end-of-turn asynchronous calls helps with the
multiple independent listeners problem. If a listener can mutate the DOM,
then change-listeners depend upon change-listeners. The relative timing of
the listener calls and the non-listener DOM mutations does not change that

And once change-listeners mutate the DOM then the API of "here are the
changes from this turn" again misleads the developer relying on it.

(I think simplifying the internal browser logic for DOM mutation is all the
justification needed for new API for DOM mutation observers).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120819/e2b57b42/attachment-0001.html>

More information about the es-discuss mailing list