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