Re: All ECMAScript attributes should be non-configurable

On Sep 30, 2011, at 11:05 PM, David Bruant wrote:

> Travis Leithead a écrit :
>> +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.
> What performance issue are you refering to? Brendan's argument was actually that this design was better in terms of performance.

I didn't argue for non-configurable methods. The prototype-based accessors are a different story, but currently they are configurable. Obviously all browsers today optimize JS including proto-properties on DOM prototypes which are configurable. That ship sailed, it's still sailing.


> 
>> 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.
>> 
>> http://blogs.msdn.com/b/ie/archive/2011/04/27/ie9-compat-inspector.aspx
>> 
>> 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.
> From the code I have read, the tool only replaces some functions ("operations" in WebIDL terms). Not attributes. By "attributes", I refer to the definition in WebIDL: http://www.w3.org/TR/WebIDL/#es-attributes . This is also the definition I used in my original message when I was talking about "attributes".
> As you can see, "attributes" do not cover "operations". Operations are configurable as they have always been. It's a great feature, i don't want to change it.
> 
> Currently, in Chrome, attributes are not inherited. Operations are, but attributes are not. Attributes are exposed as own properties when the object (event for instance) is created. This guarantees by design, that all event object have a "target" property for instance.

That's a WebKit DOM feature, IINM. Same goes for Safari, IOW.


> This guarantee is lost in WebIDL because of inheritance + non-configurability. I think it's a loss. You may disagree and i'd would like to hear arguments against it.
> 
> As said Brendan (http://lists.w3.org/Archives/Public/public-script-coord/2011JulSep/0457.html ): "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."

Please note that I'm not worried about the destroy-the-world hazard. You are. I just raised the alternative design for consideration.


> So I don't really see what is the problem with having attributes (and only attributes, not operations!) non-configurable.

It's a bit of non-configurable yin in a sea of configurable yang. That's the main objection.

/be