Expressing that a property is non-deletable (was: Function identity of non-configurable accessors)
{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 ...
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.
2012/12/18 Mark S. Miller <erights at google.com>
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.
The deeper issue pointed out by David here, I think, is that the triplet {enumerable,writable,configurable} does not cover the entire possible space of what one might want to express about the behavior of a property.
If I understand correctly, the concrete case here is a property that cannot be deleted (which is normally expressed as configurable:false), but which should still remain configurable.
I think it is unpractical and unwieldy to bake new attributes in to the ES spec for every use case that pops up.
However, in the context of proxies, we have previously talked about the usefulness of allowing handlers to accept custom attributes in their defineProperty trap and return custom attributes from their getOwnPropertyDescriptor trap.
By analogy, it might make sense for WebIDL-specified host objects to return additional custom attributes to describe the behavior of special properties that cannot be captured by {enumerable,configurable,writable}.
The remaining "problem", of course, is that there is no standard semantics for custom attributes. As mentioned by Allen in another thread, the only solution here is for an exotic object to properly document its interface, including what meaning it ascribes to any custom attributes it wishes to report or accept.
didn't know about that custom possibility so yes, I guess we are OK here, thanks for the update.
br
Le 18/12/2012 18:08, Brendan Eich a écrit :
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] esdiscuss/2012-December/027200