W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Interaction between WebIDL operations and ES6 proxies

From: David Bruant <bruant.d@gmail.com>
Date: Thu, 31 Jan 2013 17:54:47 +0100
Message-ID: <510AA1D7.4040409@gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:09 UTC