W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: All ECMAScript attributes should be non-configurable

From: David Bruant <david.bruant@labri.fr>
Date: Sat, 24 Sep 2011 00:53:30 +0200
Message-ID: <4E7D0DEA.5020300@labri.fr>
To: Brendan Eich <brendan@mozilla.org>
CC: public-script-coord@w3.org
Le 23/09/2011 21:37, Brendan Eich a écrit :
> On Sep 23, 2011, at 12:31 PM, David Bruant wrote:
>
>> Hi,
>>
>> In the current form of WebIDL, if i run the following code (in a
>> WebIDL-compliant environment):
>> -----
>> var o = Event.prototype;
>> delete o.currentTarget; // works with any other attributes
>> -----
>> Then, all events afterward will not have a currentTarget property (since
>> it's gone from the interface).
>> In the DOM event spec, "currentTarget" is defined as an attribute on the
>> Event.prototype object. This property must be a configurable (since not
>> [[Unforgeable]]). Consequently, any script can remove it and events will
>> no longer have a currentTarget property which is not what anyone want.
>>
>> Consequently, I would suggest to consider all attributes to be
>> non-configurable regardless of [[Unforgeab(le)]]-ility.
> Why is this a good idea? There are many ways to modify standard constructors and their prototypes, some destructive. Is it really important to forbid such freedom, just because one can make a mess?
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?

David
Received on Friday, 23 September 2011 22:54:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC