Re: All ECMAScript attributes should be non-configurable

Le 24/09/2011 02:58, Brendan Eich a écrit :
> On Sep 23, 2011, at 5:54 PM, David Bruant wrote:
>
>> Le 24/09/2011 02:52, Brendan Eich a écrit :
>>> On Sep 23, 2011, at 3:53 PM, David Bruant wrote:
>>>
>>>> Currently, on Chrome and Opera (12), event attributes are configurable
>>>> own properties (data in the former, accessor in the latter).
>>>> Consequently, the freedom to prevent all events to have a "type" or
>>>> "target" attribute doesn't exist by design.
>>>> Do anyone miss that freedom? In other words, are there use cases of
>>>> wanting this freedom at all or is it just a side-effect of putting
>>>> properties on the prototype and defaulting to configurable=true because
>>>> a choice has to be made?
>>> The "own" vs. prototype design is intentional. The non-configurable is too.
>> What is the rational behind each of these decisions?
> AIUI, "own" costs a direct property per instance, reified. "prototype" obviously does not.
What do you mean by "cost"? Is it purely an implementation concern? If
so, it doesn't seem to be for Opera and Chrome currently.
Regardless of ECMAScript representation (own or inherited properties),
the same information has to be stored in a way or another. Maybe as own
property values, maybe hidden in some sort of internal WeakMap or hidden
field, but the difference seems more cosmetic than anything else. Do you
have benchmarks or anything that could help understand the
implementation cost difference?

Unless you meant something else by "cost"?

> Sorry, I meant to write "configurable", not "non-configurable". Not sure why that's there. A non-configurable prototype property could not be deleted, which would remove the destroy-the-world hazard. It could still be shadowed, but not by assignment -- only by Object.defineProperty.
Exactly :-)

David

Received on Saturday, 24 September 2011 01:12:41 UTC