Expressing that a property is non-deletable

David Bruant bruant.d at
Wed Dec 19 05:51:13 PST 2012

Le 18/12/2012 20:09, Mark S. Miller a écrit :
> I see no reason why this needs to be a reflected property. As to
> whether it is an exotic internal property or just prose, that is a
> specification expository issue for which I defer to Allen. But the
> spec only needs such extra state for the exotic global object. There's
> nothing general about it.
I fully agree on the fact that if there was a "deletable" attribute it 
would be "local" to the global object and wouldn't need to be an 
attribute reflected on all objects.
In ES5, we've been thinking of property attributes as absolute thing 
that apply to every single objects. Maybe it's time to give each sort of 
object a little bit of freedom to explain how their properties work, to 
allow the reflection methods to describe their internal contract more 
accurately than they currently can with 
In this case, maybe there is value in having WindowProxy objects telling 
us whether or not a property is deletable or not (because the 
configurable boolean which is used for that in other objects doesn't 
have the same semantics here).

Maybe numerical attributes of NodeList could provide a "live" or 
"syncWithDOMTree" attribute clearly showing that they are not your 
regular numerical properties.

I'm putting maybe-s because I don't know if there is value in doing 
that, but the point I am trying to make is that this can be the way out 
to enable all objects to respect invariants while allowing different 
objects to express their internal contract.


> On Tue, Dec 18, 2012 at 10:56 AM, Andrea Giammarchi
> <andrea.giammarchi at> wrote:
>> {deletable: false} does not look that bad, semantically speaking ... you
>> don't have to explain much what that would do in a property descriptor.
>> Thing is, all others are false by default so you might want to chose same
>> default for this property and in this case the name is wrong.
>> {nondeletable:false} looks like a typo while {sealed:false} for the single
>> property would be probably better? {sealed:true, configurable:true} means
>> non deletable and {sealed:true, configurable:false} could mean even
>> inherited properties cannot be re-defined while sealed:false would be the
>> default?
>> Or maybe not ...
>> On Tue, Dec 18, 2012 at 9:31 AM, David Bruant <bruant.d at> wrote:
>>> 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]
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at

More information about the es-discuss mailing list