Expressing that a property is non-deletable

David Bruant bruant.d at
Wed Dec 19 05:34:07 PST 2012

Le 18/12/2012 19:56, Andrea Giammarchi a écrit :
> {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.
+1 on "deletable" and +1 on defaulting to false.

> {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 ...
I'm not entirely convinced by "sealed". The semantics of this new 
attribute would be about the effect of the "delete" operator, so I think 
it makes sense for it to have some "delete" in the name.


> On Tue, Dec 18, 2012 at 9:31 AM, David Bruant <bruant.d at 
> <mailto: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 <mailto:es-discuss at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list