Re: Interaction between WebIDL operations and ES6 proxies

On Thursday, January 31, 2013, David Bruant wrote:

> 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.


Isn't the intention of WebIDL to be language agnostic? To be clear, I agree
that there needs to be behaviour specification for the DOM w/r to Proxy.
I'm interested in the implications of WebIDL attempting to specify a
language specific behaviour without using that language's own spec language.

Rick



> Thoughts?
>
> David
>
> [1] http://wiki.ecmascript.org/**doku.php?id=harmony:direct_**proxies<http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies>
>
>