Dynamically changing of loader global

Brendan Eich brendan at mozilla.com
Fri Dec 28 00:23:36 PST 2012

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?


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
> <brandon at brandonbenvie.com>  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.

More information about the es-discuss mailing list