RE: All ECMAScript attributes should be non-configurable

+IE9 (another example using configurable properties--as accessor properties on the prototypes). We did work around the performance issue using caches, as most sites don't mess with the configurability of the properties.

We [Microsoft] are strong supporters of the "configurable" DOM type-system. While you can "destroy-the-world" you can also use that power for good (with great power comes great responsibility :). Thanks to configurable properties, we were able to build a very useful tool to help all web developers identify potential compatibility problems on their web sites.

The tool is simple and replaces built-in DOM APIs with an inspection layer before funneling the calls through to the actual APIs. If the various accessor properties weren't configurable this tool would not be possible.

>-----Original Message-----
>From: [mailto:public-script-coord-
>] On Behalf Of Brendan Eich
>Sent: Friday, September 23, 2011 5:53 PM
>To: David Bruant
>Subject: Re: All ECMAScript attributes should be non-configurable
>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.
>The combination does make a destroy-the-world button. But is it really a
>problem? Same thing can happen with Object.prototype.toString.

Received on Sunday, 25 September 2011 03:01:22 UTC