From: Alex Russell Sent: Thursday, August 30, 2012 7:44 PM To: ste...@stevensanderson.com Cc: 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> 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 https://mail.mozilla.org/listinfo/es-discuss
