Expressing that a property is non-deletable (was: Function identity of non-configurable accessors)

David Bruant bruant.d at gmail.com
Tue Dec 18 09:31:31 PST 2012


Hi,

Le 18/12/2012 18:08, Brendan Eich a écrit :
> Mark S. Miller wrote:
>> That could work, but because of its complexity, I'm leaning back 
>> towards the "configurable data property that refuses to be 
>> configured" approach. Is there a problem with that? It self-hosts fine.
>
> Certainly this is the simplest solution. It has a slight smell, but no 
> worse than the others'!
In an earlier message [1] I suggested that "enumerable" was more of a 
convention than an actual semantics. Indeed, neither host objects nor 
upcoming proxies are expected anything when it comes to "enumerable". 
However, a script can have some expectations that a property defined 
and/or reflected as enumerable: true will show up in for-in and 
Object.keys while won't if enumerable: false.

One idea to reduce the smell of configurable-yet-non-deletable 
properties would be to add a new "nonDeletable" attribute (I'm not happy 
with the negation, but can't find a better wording). Just to clarify, 
this attribute doesn't need to be defined on every property of every 
object, only in cases where one could expect configurable:false for the 
[dontDelete] part, but configurable is actually true for other reasons.

In our case, this attribute would be relevant for both WindowProxy 
global var/functions and [Unforgeable] properties of the same object. 
This way, "host objects" and proxies have a convention when they want to 
express to the code that interact with them that a property can't be 
removed by use of the "delete" operator, but the property may disappear 
by other means (in the case of WindowProxy, change of the underlying 
window).

Defining the "nonDeletable" attribute (or whatever better name) is a 
decision that could be fully made on the WebIDL side, because it defines 
host objects and host objects can define their own properties, but I 
think it's important the convention emerges from the ECMAScript side.

David

[1] https://mail.mozilla.org/pipermail/es-discuss/2012-December/027200.html


More information about the es-discuss mailing list