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