On 12/28/12 12:24 PM, Brendan Eich wrote:
David was questioning the new status quo, which is fine -- we benefit
from being skeptical of our theories, as Feynman recommended. He was
motivated by the extra complexity of ES5 accessors, which can be
reflected on, extracted as get and set functions, called on wrong objects.
Extra complexity compared to _proxies_? Seriously?
Which sort of complexity are we worried about? Implementation
complexity? Complexity for people trying to use the web platform?
Specification complexity? Something else?
I'm happy to consider arguments that things are too complex, but I'd
like to understand the arguments. ;)
Note that in practice Gecko's implementation basically treats setters as
single-argument methods and getters as 0-argument methods and shares the
code for getters/methods/setters under the hood, so since methods
already have to handle being called on wrong objects the complexity is
pretty low for the DOM code. The complexity of setting up acccessor
properties is also pretty low since JS engines already support that.
There's a bit of complexity in the JIT to make some of this stuff
faster, but nothing even remotely comparable to trying to make proxies
fast...
Your reply helps a lot, IMHO, in reaffirming why WebIDL, with Gecko, and
Trident implementing, chose prototype-homed accessors. JITting
proto-accessors is a thing engines already do. JITting through proxy
traps (ignoring dummy target overhead) is in the future.
It's even worse than that. Without certain behavior guarantees on the
part of the proxy (which in this case would not be implemented in JS,
note, so would not be able to be analyzed by the JIT) it's impossible to
JIT through those traps.
Of course one could try to reimplement the entire DOM in JS; that way
lie other performance pitfalls.... And even then, safely calling proxy
traps has a bunch of overhead unless you can prove they don't do certain
things.
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. ;)
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
