[Sorry, this time from the right email] Object.deliverChangeRecords allows A to be a strategy in the possible future that Steve describes (if reads were to generate changeRecords)
[Just to be clear: I *don't* think it makes sense to include reads in the set of changeRecords generated by Object.observe() at this point] The basic idea is that every "computed property" has "around advice" that clears its pending delivery queue before and after invocation of the actual function so it can disambiguate reads generated during the invocation from outer (previous or later) or inner (sub-invocations of computed properties) reads. On Wed, Sep 19, 2012 at 2:09 PM, Brendan Eich <bren...@mozilla.com> wrote: > From A, B and C as alternatives, especially A and C, it seems you want > synchronous read intercession, but are happy with Object.observe's > asynchronous write intercession? > > If so, then the plan interference objection is fatal. > > If not, then how would async read intercession work? Callbacks and promises > are not going to fly. > > /be > > Steve Sanderson wrote: >> >> Following this discussion, Rafael and I talked about various strategies >> that an MV* library could use to detect dependencies from arbitrary >> expressions and code blocks, as would be needed to achieve the kinds of >> niceties present in Knockout.js/Batman.js etc. Some of these tie in with >> Object.observe more than others. >> >> The upshot is that we don't have a single most compelling way to do this >> kind of dependency detection with Object.observe, but it would be possible >> to augment Object.observe to add that ability in a future language version >> (see technique A below), or alternatively, libraries could use somewhat less >> clean techniques to achieve it with proxies/accessors alone, regardless of >> Object.observe (see techniques B and C below). >> >> So as a library developer I would in principle be happy to see >> Object.observe added to ES, since it appears to be a step in the right >> direction. But I would caution that unless read notifications were added >> (see technique A), my library (knockout.js) couldn't use it to achieve >> something as clean as its existing semantics, so we'd most likely be waiting >> for future improvements before being able to use Object.observe. >> >> Regards >> Steve >> >> *_Appendix: the techniques we considered_* >> >> * *Technique A: Add read notifications to Object.observe (either >> now, or in a future ECMAScript version)* >> o Just as the existing Object.observe proposal delivers >> >> notification of property writes for specific objects, a >> symmetrical API could deliver notification of property reads >> for specific objects >> o Pros: it requires no proxies or accessors, so works with raw data >> o Cons: requires language support, like Object.observe does for >> write notifications >> * *Technique B: Membrane-style proxies transitively capture all >> chains of properties read from a given object* >> o The logic that parses/evaluates binding expressions could >> >> supply a specially wrapped version of the underlying data that >> uses a proxy to log property reads >> o Pros: doesn't require language support; ties in with >> >> Object.observe in that once you know what properties were >> read, you can use Object.observe to subscribe to write >> notifications >> o Cons: because the proxies aren't the real underlying data >> >> objects, it's possible to get into confusing scenarios where >> things don't work, for example if you read a property of a >> closure-captured variable, that won't be logged and hence the >> framework can't auto-update when that property changes >> * *Technique C: Monkeypatch all model data properties with accessors >> that log reads* >> o Some utility function would walk the object graph and replace >> >> all properties with special accessors >> o Pros: doesn't require language support; also doesn't even >> >> require Object.observe since you might as well also replace >> setters with ones that trigger notification on change >> o Cons: very intrusive - permanently modifies the developer's >> data structures >> >> >> >> On Fri, Aug 31, 2012 at 10:38 AM, François REMY <fremycompany_...@yahoo.fr >> <mailto:fremycompany_...@yahoo.fr>> wrote: >> >> *From:* Alex Russell <mailto:slightly...@google.com> >> *Sent:* Thursday, August 30, 2012 7:44 PM >> *To:* ste...@stevensanderson.com <mailto:ste...@stevensanderson.com> >> *Cc:* es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> >> *Subject:* Re: Object.observe and observing "computed properties" >> >> On Wed, Aug 29, 2012 at 11:09 AM, Steve Sanderson >> <fla...@gmail.com <mailto:fla...@gmail.com>> wrote: >> >> Knockout developers are used to this sort of thing updating >> automatically whenever you modify the price of any item, or >> when you add or remove items to the array. It would be very >> inconvenient to have to somehow declare dependencies manually >> (2a) - I'm not even sure what kind of syntax or mechanism you >> could use when the set of dependencies changes over time. That >> leaves option (2b) which works great, as long as dependency >> detection is built into observability. >> >> I'm not sure that's true. Side-effects are a real pain and it >> seems to me that there's going to be some practical advice at the >> bottom of any of these systems that says, in effect, "don't do >> things we can't understand". That sort of advice is likely to be >> backed up with tools to assist you in helping developers >> understand those limits; say transpiler passes that analyze the >> dependencies in a function. >> Using a transpiler to detect the dependencies would be very >> difficult; avoiding memory leaks seems nearly impossible in this >> case. KnockoutJS features automatic dependency detection for years >> and I don’t think it has raised any issue at this time. Developers >> do not bind an UI element to a function that actually does >> something else than formatting a value or doing a computation (ie: >> readonly methods). I think it would be safe to say that, in >> “dependency tracking mode” the observable objects are read-only >> (you can’t modify them or it throws) so that it’s impossible to >> use ill-suited methods as a source of binding. >> Also, to continue on your ‘transpiler’ idea: how would a >> transpiler work to detect changes to the dependency properties? >> Would you require JS code to receive *every* read and write >> notifications for all properties observable objects (like it’s the >> case in Object.observe), filter them to find the interesting bits, >> and mark themselves the modified properties and the bindings which >> are not up-to-date anymore? >> In such case, a proxy polyfilling the API I propose will be way >> smarter... >> It strikes me that this is at some level a question of how deep >> your analysis of the target function is willing to go. So far the >> examples dependencies are only on in-scope objects inside a >> computed property's generator. But what about methods called there >> that might have inputs that change? How deep does the propagation go? >> If the arguments of the method “touch” observable objects, they >> will be watched for modifications, just like any other dependency. >> If they are static, they will not fire traps in observable objects >> and will not cause overhead. >> It seems that the implicitness of this strategy implies that some >> computed properties will be *always* marked "regenerate" as it'll >> be simpler/easier/faster than doing something more sophisticated. >> Could you develop? I don’t get that issue. >> >> Overall, I've no wish to derail the Object.observe proposal, >> and fully accept that dependency detection might end up being >> out of scope for it. However if the ES recommendation will end >> up being "solve this problem through convention, not language >> support", I'd love to have a sense of what kinds of >> conventions (examples, preferably) we would actually be >> recommending and how they would offer a similar level of >> convenience to dependency detection. >> >> I don't think they will, frankly. The best of them will re-create >> dependency detection via compiler. The less aggressive may simply >> force enumeration of dependencies or create conventions which >> cause particular properties to be observed through participation. >> Avoiding memory leaks using a compile-time dependency tracking >> seems a nightmare to me, and detecting affected bindings would be >> a bummer. Bad idea flag raised. >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org <mailto: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 > > _______________________________________________ > 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
