The trade-off is not between own data properties and shared
prototype-homed accessors.
Rather, it is between own and inherited accessors.
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).
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).
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?
/be
Mark S. Miller wrote:
So does anyone know why? Own properties were the obvious choice, so
there must have been some reason to choose inherited accessors
instead.
On Thu, Dec 27, 2012 at 11:32 AM, Brandon Benvie
<[email protected]> wrote:
It's definitely been my experience that accessors, as found in IE and
Firefox, are much more fidgety and error prone than own data properties, as
found in WebKit. The fact that it becomes possible to call them on invalid
targets and that it's no longer possible for a debugger to simply display
own properties exacerbates this fidgetyness. Even worse, the prototypes
which the accessors live on are themselves not valid targets, which
basically invites errors.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
