WebIDL attribute reflection (was: Dynamically changing of loader global)

David Bruant bruant.d at gmail.com
Fri Dec 28 02:01:12 PST 2012


Le 28/12/2012 09:23, Brendan Eich a écrit :
> The trade-off is not between own data properties and shared 
> prototype-homed accessors.
>
> Rather, it is between own and inherited accessors.
True. The reason is that WebIDL attributes have types that need to be 
enforced [1] among other things.

> In either case, one needs per-instance state, often stored in a 
> peer-to-JS C++ DOM native data structure that must exist whether 
> there' s a JS reflection.
>
> But with own accessors, one also then needs another slot or pair of 
> slots (for setter and getter).
These could be created lazily on Object.getOwnPropertyDescriptor or 
Object.defineProperty calls, no?

> It's not enough to make a magic data property with code backing it to 
> compute or normalize or commit other effects on get and/or set. We 
> can't model magic own data properties that involve computed get/set in 
> WebIDL or ES5 (or ES6, outside of proxies).
Proxies sound like an interesting option to explore.
An ES6 proxy-based implementation could have own data properties and 
perform the type checks/coercion as necessary. Reflecting as own 
properties may also simplify the WebIDL attributes getter/setter 
algorithms, at least by removing the checks on |this| (since 
getter/setters couldn't be extracted anymore).
As you say, the per-instance storage would be exactly the same.

> So economics come in, and shared accessors win big-time on efficiency.
>
> The key insight is that the per-instance storage does not change 
> between alternative own vs. inherited accessor scenarios, but own adds 
> extra slots to every instance. That hurts.
>
> Pre-WebIDL DOM bindings cheat by using native code to run on every set 
> and even get, without the own data property reflecting as an accessor. 
> That seems worse than what we have settled on with prototype-homed 
> inherited accessors, no?
I'm not 100% sure. In a world with proxies, "code to run on every set 
and even get without the own data property reflecting as an accessor" 
will be legion; that's almost the definition of a proxy.
As long as WebIDL properly defines the semantics of this code, I don't 
see the problem. This joins Allen's recent point about exotic objects 
having to properly specify their semantics [2]

What was bad with the native code run on get/set was that the behavior 
was unspec'ed and non-interoperable between implementations. If WebIDL 
fills the gap, things become much better.

Using ES6 proxies semantics to explain own data properties in WebIDL would:
* be neutral when it comes to storage
* simplify the getter/setter attributes algorithms (remove |this| 
checks, maybe other things due to non-extractability)
* solve the ocaps API issue
* solve the convenience issues raised by Brandon

The balance looks positive to me.

David

[1] http://dev.w3.org/2006/webapi/WebIDL/#es-attributes
[2] last paragraph of 
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027224.html


More information about the es-discuss mailing list