- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 04 Aug 2010 15:42:33 -0700
- To: Travis Leithead <travil@microsoft.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Cameron McCormack <cam@mcc.id.au>, "Sam Weinig (weinig@apple.com)" <weinig@apple.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Aug 4, 2010, at 11:36 AM, Travis Leithead wrote: > Sure. > > Not only does ES5's configurable: false property prevent deletion, but it also prevents changing a property from a field to an accessor and vice-versa, as well as changing the getter/setters of the property. > > So, the following wouldn't work if the "appendChild" property was configurable:false: > > Object.defineProperty(Node.prototype, > "appendChild", > { get: function() { /* custom getter replacement */ }, > set: function(x) { /* custom setter replacement */ } > }); > > ... which is the ES5 way of doing: > Node.prototype.__defineGetter__("appendChild", function() { /* custom getter replacement */ }); > Node.prototype.__defineSetter__("appendChild", function(x) { /* custom setter replacement */ }); > > So, configurable: false prevents users from replacing built-in properties with getter/setters. I think this is too restrictive, especially forward-looking considering how much the DOM is changing and evolving. I don't see why you would want to do that. The common way to override the behavior of DOM operations is: Node.prototype.appendChild = function(node) { /* replacement function */ } I think what you describe is not commonly done, or particularly useful. Furthermore, prototype hacking is primarily used for additions, not replacements, which are not impacted by this at all. Likewise, I don't think it's common to want to add a setter for the window.Node global interface object. Regards, Maciej > > -----Original Message----- > From: Jonas Sicking [mailto:jonas@sicking.cc] > Sent: Tuesday, August 03, 2010 5:22 PM > To: Travis Leithead > Cc: Cameron McCormack; Sam Weinig (weinig@apple.com); public-webapps@w3.org > Subject: Re: [WebIDL] interface objects and properties too restrictive? > > On Tue, Aug 3, 2010 at 4:57 PM, Travis Leithead <travil@microsoft.com> wrote: >> Hey folks, just wondering what the justification behind the current >> {DontDelete} semantics are in WebIDL 4.4 [1] and 4.5 (second bullet) >> [2]. When our IE9 binding ported this to ES5, it translated to >> "configurable: false", which completely destroyed the ability to set >> accessors on the interface objects as well as operations (and in our >> case, DOM accessors). Because of this, we actually don't mark our >> interface objects OR operations/attributes as configurable: false, >> rather configurable: true.* >> >> If this seems reasonable, I'd like to see the spec updated. > > Sorry, I'm not very updated on the differences between the ES3 and ES5 worlds. Why does "configurable: false" destroyed the ability to set accessors? Can you give an example of a piece of script that doesn't work but which you'd like to work, and what you'd like it to do? > > / Jonas > >
Received on Wednesday, 4 August 2010 22:43:07 UTC