Boris, what initially triggered my questioning of the inherited accessor
setting is in this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html
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
semantics.
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
Object.getOwnPropertyDescriptor?
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?
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
