Proxying Native Objects: Use case

François REMY at
Thu Jan 31 08:26:11 PST 2013

> > Let's say I want to implement a polyfill for MapEvent whose definition is as follows:
> >
> > interface MapEvent : Event {
> > getter any item(DOMString name);
> > }
> Out of curiosity, where does MapEvent come from? I can't remember having
> read about it on any spec and Google isn't helping.

Just to make it clear, it doesn't come from any spec. 

I'm currently working on a WebIDL implementation in JavaScript (so: take any piece of WebIDL, generate a stub for it that works as expected) so even if 'getter' isn't that beautiful I still want it to work. We could also envision getter being used as in indexer for array-like types.

The fact is: a polyfill cannot entirely live in the user world because at some point it will have to rely on browser features (dispatchEvent in this case). If a polyfill is not able to trap the [[...]] traps of a 'native-branded' object, it will fail to simulate some of its behavior properly if the polyfilled object involves proxy-like operations.

The goal is not to get the browser use the proxy traps, it's just to have any user code to use the proxy traps like any user code can actually use the expandos made on native objects today.

> I think such a getter notation exists in WebIDL to formalize scars from
> the past (like HTMLCollection) rather than to be used in new APIs

Yes and no. For exemple, something alike is envisionned to support custom properties in CSS. Something like: = true;
    // set the my-custom-property custom CSS property

> For this kind of API, I largely prefer the CustomEvent approach where
> the (unique!) "detail" field is by-spec expected to be a "go crazy" type
> of field. The "detail" attribute also doesn't collide with any existing
> field; in the MapEvent case, a getter could shadow an inherited property.

I agree nobody would ever do that. That was just a minimal sample that used getter and a native brand at the same time. We could imagine more realistic and more complex patterns, that would just make the discussion more complex ;-)

> However, off top of my head, I don't see a main restriction to call
> .dispatch with a proxied event as argument. I'm not enough expert of
> this topic; people who are in how the APIs are used and implemented will
> better tell whether it's appropriate to accept a proxy.
> I'll post to public-script-coord to talk about that.

Thanks, that's a good idea. But you didn't comment on the possibility to simply turn any object into a proxy using 

    obj[Object.__Get__] = function getter() {} 


    function wrap(obj) { 
        var old = Object.getProxy(obj); 
        Object.setProxy(obj, {...});

To me, it remains the best option when you work on native objects. You get proxy-traps-expandos in the JS world and no impact in the native world. 


More information about the es-discuss mailing list