RE: Interaction between WebIDL operations and ES6 proxies

> I thought a large part of the motivation for proxies was about being
> able to do the kind of things that happen in API land. If that is not
> feasible, or at least not in all cases, what is left?

This is why this thread came up in fact. I was discussing the fact that polyfills could not hybrid safely native objects if proxies were not auto-unwrapping. See [[https://mail.mozilla.org/pipermail/es-discuss/2013-January/028528.html]] for more details.

I don't know if there's a real solution to this (maybe there's not) but at least we should consider this closely. I don't know if this is feasible but ideally the Extensible Web Community Group would like his ECMAScript WebIDL implementation to be able to add the getter and setter semantic to native objects, probably with a solution like:

    CSSStyleDeclaration.prototype[Object.noSuchGetter] = function(propertyName) {
        // handle the case of custom properties
    }
    CSSStyleDeclaration.prototype[Object.noSuchSetter] = function(propertyName,value) {
        // handle the case of custom properties
    }
    CSSStyleDeclaration.prototype[Object.noSuchDeleter] = function(propertyName,value) {
        // handle the case of custom properties
    }

And those functions would be called when a property is being created on the wrapper object (noSuchSetter) or when a read operation fails (noSuchGetter) or when a property is deleted via 'delete'. Both would be private names to avoid naming issues and would allow most of the cases where getter/setter are required in WebIDL (maps, arrays and infinite sets of properties).

So... please?



For real proxies, however, the bottom line seems however to be:

- if a native class should support proxying, then we should add a [[Proxyable]] attribute to the class interface. That attributes is reflected in ECMAScript with a static method on the class named  'createProxy' that would allow you to create an instance of the class whose ECMAScript counterpart is a proxy (that would not affect native algorithms, only ECMAScript access to the objects). With this solution, a native element may be represented by exactly one proxy in the JavaScript world, and never by its target. We keep one-to-one mapping between a native element and an ECMAScript wrapper. For polyfills, this is okay.

    Image.createProxy({ ..proxy things..}, ..rest of arguments..)
    document.createElementProxy({ ..proxy things.. }, ..rest of arguments..)

- if a specific method should support proxying, [[Proxyable]] should be set on the argument type. Then, it's up to the method to specify what happens is a proxy is used instead of a real instance.

    void dispatchEvent([[Proxyable]] Event e);

Received on Friday, 1 February 2013 09:53:25 UTC