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

Andrea Giammarchi andrea.giammarchi at
Tue Dec 18 10:56:20 PST 2012

{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

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]**pipermail/es-discuss/2012-**
> December/027200.html<>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list