- From: David Bruant <bruant.d@gmail.com>
- Date: Thu, 31 Jan 2013 17:54:47 +0100
- To: "public-script-coord@w3.org" <public-script-coord@w3.org>
Hi, # Proxies and what they change to what we know ECMAScript 6 introduces proxies [1]. A proxy is composed of a target which can be any object and a handler which defines some behavior (on property access, freeze, property enumeration, etc.). Ideally, a proxy transparently emulates the target it "wraps". For instance, a proxy which target is a DOM Node would be seen as a Node. However, reality is a bit more complicated. To start with, proxies expose the guts of spec algorithms in ways that weren't possible before. For instance, run this in Firefox: var a = [1, 7, 9, 3, 2, 0, 4, 8, 6, 5]; var observedOrder = [] var pa = new Proxy(a, { get: function(target, name){ observedOrder.push(name); return target[name] }, set: function(target, name, value){ observedOrder.push({name: name, value:value}) return target[name] = value } }) pa.sort() console.log(observedOrder) You can observed that Firefox first pulls all array values, (then runs an algorithm of its own), then puts them back sorted in one batch. Before proxies, this kind of things couldn't be observed. As you can imagine it applies to every single algorithm, including the WebIDL ones I guess. Hopefully, by now, you're scared as much as I am of the potential implementation inconsistencies proxies can reveal. # Proxies aren't suitable for all usages A discussion on es-discuss with Boris Zbarski revealed that if proxies wrapping DOM Nodes could be inserted in the DOM tree, then they would likely reveal how and when selector matching is performed by the browser which is vastly undesirable because selector matching can be done in parallel. Also, in one of the handler trap, the tree could be modified, ruining selector matching. I would like to believe this is an exception, but probably not. I think every spec will have to specify how the algorithms interact when being passed proxies to the object they're supposed to interact with. # Default behavior I think the safe default (which should probably be put in WebIDL) is to not accept proxies in function arguments, as this value, etc. and throw when seeing one. At least that's future-proof. # Revising each spec to take proxies into account Given the above default each spec will have to opt-in to say whether it considers a proxy to one of its objects as a legitimate object. The above default allows to decentralize the decision so that each spec to make the decision on its own time. It would make sense to send an email to everyone defining JS APIs to tell them about proxies and that they have to make a decision, but I wouldn't know how to procede for that. Thoughts? David [1] http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies
Received on Thursday, 31 January 2013 16:55:19 UTC