WebIDL attribute reflection

David Bruant bruant.d at gmail.com
Sat Dec 29 11:08:15 PST 2012

Boris, what initially triggered my questioning of the inherited accessor 
setting is in this message: 
Mostly concerns about a mix of API "securability" and convenience. I 
"demonstrate" that if every attribute is an inherited accessor, then, 
it's possible to secure the environment, but it can be at the expense of 
API usability up to asking people to tweak their code (which is an 
anti-goal when trying to secure your code from, say, an advertiser's code)

Le 28/12/2012 22:18, Boris Zbarsky a écrit :
> On 12/28/12 12:31 PM, Boris Zbarsky wrote:
>> When we have gets through a proxy down in the 20-30 cycle range on
>> modern hardware, I'm happy to talk about proxies performance-wise.  ;)
> One other note.  I'm somewhat sympathetic to the argument that the 
> spec could describe things as proxies while actual implementations 
> then implement them however the heck they want under the hood.
I was half-clumpsy (I mentioned "An ES6 proxy-based implementation" by 
mistake), but it was what I was asking for. That's what I tried to 
express when I wrote "Using ES6 proxies semantics to explain own data 
properties in WebIDL would..."
 From the beginning, I wanted to have a spec/semantics discussion. 
Implementations are free to do whatever they want as long as the 
observable behavior is conformant.

WebIDL tries to close the gap between DOM semantics and ECMAScript 
semantics. In an ES5 world, the only thing that can explain the magic 
behavior is getters/setters (own or inherited). In an ES6 world, proxies 
can be an explanation too.
For some cases like WindowProxy or NodeList, there will be no other way 
than using proxies  to specify these objects in an ECMAScript replicable 

> But that does involve each implementation then going through and 
> creating yet another kind of thing internally which is not a proxy so 
> it can be optimized sanely but still has some sort of behavior that 
> isn't describable by normal getters/setters or normal value 
> properties, so it's actually more implementation complexity than what 
> WebIDL has right now, as far as I can tell.
I'm not sure I'm convinced by "it's more work than right now". If you 
had told me that there is a fundamental issue that implementors can't 
work around when exposing own data properties, I would have backed out, 
but you suggested than it's possible to create "yet another kind of 
thing internally which is not a proxy so it can be optimized sanely".
Is there some sort of way to use the getter/setter based implementation, 
but expose things as data property when asked via 

> And possibly more specification complexity too.  For example, right 
> now WebIDL doesn't have to define what happens when you try to delete 
> DOM properties, because it's obvious, but once you try to use a proxy 
> you have to define that sort of thing.
Not with the direct proxy design. I think that the role of a spec using 
ES6 proxies as a spec tool would only be to define the different traps. 
Just say "there is no delete trap" and what happens when you try to 
delete becomes as obvious as how things are currently. Repeat with 
"keys", "getOwnPropertyNames" and most traps actually.
One only needs to define the get/getOwnPropertyDescriptor and 
set/defineProperty traps which is the work that the spec is already 
doing at different places.
I don't feel it would add complexity; it would just be different.

Out of curiosity, do you have an idea of how much cost the |this| check?


More information about the es-discuss mailing list