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 <johnjbar...@johnjbarton.com>wrote: > > > On Fri, Aug 17, 2012 at 9:49 PM, Rafael Weinstein <rafa...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
