> > 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:
element.style.myCustomProperty = 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() {}
or
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.
François
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
