- 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