WebIDL attribute reflection (was: Dynamically changing of loader global)
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  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 
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.
 last paragraph of
More information about the es-discuss