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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
