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

Andrea Giammarchi andrea.giammarchi at gmail.com
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
default?

Or maybe not ...


On Tue, Dec 18, 2012 at 9:31 AM, David Bruant <bruant.d at gmail.com> 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] https://mail.mozilla.org/**pipermail/es-discuss/2012-**
> December/027200.html<https://mail.mozilla.org/pipermail/es-discuss/2012-December/027200.html>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121218/b327f2c9/attachment.html>


More information about the es-discuss mailing list