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

Alex Russell slightlyoff at google.com
Sun Aug 19 13:19:19 PDT 2012

The core improvement for Object.observe() here is that instead of
delivering *nested* changes, unrolling of observers happens one after the
other. The design of the system never puts observers on the stack on top of
each other, meaning that whatever happens as a result of code you happen to
call will be the "naked" result of that synchronous call, not the AOP-style
intercepted result.

Think after advice, not around advice.

On Sun, Aug 19, 2012 at 7:25 PM, John J Barton
<johnjbarton at johnjbarton.com>wrote:

> 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
> dependency.
> 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).
> jjb
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120819/40082c08/attachment.html>

More information about the es-discuss mailing list