François REMY wrote:

> In case you hit the "invalid cast" case, you can check if you
> received a Proxy. If you received a proxy, you retry the cast using
> its target instead.

For what it's worth, this is exactly how Gecko's WebIDL bindings work. We use something much like a Proxy to enforce cross-window security membranes, so a call to a WebIDL binding method may in fact have a "this" object or arguments that are not actual WebIDL objects but wrappers for them. This is a rare case, so we do exactly what you describe: check for a WebIDL object, then if what we have is not a WebIDL object check for a security wrapper and unwrap it as needed (the unwrapping performs a security check, which can of course fail).

So we could in fact add support for something like scripted Proxies for WebIDL objects without too much trouble in Gecko, I think. Using them would deoptimize things, of course, not only because of the extra code after the "WebIDL object" check fails, but also because it would force runtime typechecks on "this", as opposed to compile-time ones, at all callsites that used Proxies as the this object. That would not be that big a hit compared to the other things going on with Proxies, though, or so I suspect.

-Boris

P.S. Please cc me on replies; I'm not subscribed to this list. I was just pointed to this thread.

P.P.S. WebIDL objects are also normal ECMAScript objects in Gecko, except the ones that aren't because they're actually "proxies" without a target object. JSC uses objects with a custom getOwnPropertyDescriptor for similar purposes, last I looked. That said, clearly we have a way to test whether a given object is a WebIDL object, and so do other implementations.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to