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