Expressing that a property is non-deletable

# David Bruant (13 years ago)

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.

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.

David

>
>
> On Tue, Dec 18, 2012 at 9:31 AM, David Bruant <bruant.d at gmail.com 
> <mailto: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
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121219/02327a32/attachment.html>

# David Bruant (13 years ago)

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 configurable/writable/enumerable/get/set 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.

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 
configurable/writable/enumerable/get/set
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.

David

> On Tue, Dec 18, 2012 at 10:56 AM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> 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 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
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>

# Tom Van Cutsem (13 years ago)

2012/12/19 David Bruant <bruant.d at gmail.com>

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 configurable/writable/**enumerable/get/set 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.

Yes. This is exactly what I meant with using custom attributes to document exotic behavior.

2012/12/19 David Bruant <bruant.d at gmail.com>

> 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 configurable/writable/**enumerable/get/set
> 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.


Yes. This is exactly what I meant with using custom attributes to document
exotic behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121219/8055282b/attachment.html>