{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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
