This may be the right attribute combination based on what browsers implement as well, but it is not the high-integrity approach. Cc'ing some tc39ers.


/be

(In reply to comment #1)
> This may be the right attribute combination based on what browsers implement as
> well, but it is not the high-integrity approach. Cc'ing some tc39ers.

As long as an initialization script can freeze these properties before other code runs, there's no fatal problem here. But this seems weird for a concept labeled "constant", and it makes the obvious optimizations harder to implement.

Since WebIDL does have a distinct notion of "constant", and since the ConstExpr used to initialize the constant http://dev.w3.org/2006/webapi/WebIDL/#prod-ConstExpr is not something that an initialization script might plausibly want to alter, it would seem that the normal reasons for making properties initially configurable do not apply. Why not make declared constants non-writable, non-configurable data properties?

Another precedent to look at is, for example, Math.E, which is a non-writable, non-configurable data property, as are the other Math constants. (And yes, I am aware that these are speced by EcmaScript rather than WebIDL.)



> 
> /be

(In reply to comment #2)
> Since WebIDL does have a distinct notion of "constant", and since the ConstExpr
> used to initialize the constant
> http://dev.w3.org/2006/webapi/WebIDL/#prod-ConstExpr is not something that an
> initialization script might plausibly want to alter, it would seem that the
> normal reasons for making properties initially configurable do not apply.

What are the normal reasons, secure JS subsets?  I've been considering the use case of scripts wanting to add hooks into existing DOM APIs, for example as a completely synthetic use case, maybe you want to count how many times a particular property for a constant is looked up.

> Why not make declared constants non-writable, non-configurable data properties?

That's how they're currently defined.

> Another precedent to look at is, for example, Math.E, which is a non-writable,
> non-configurable data property, as are the other Math constants. (And yes, I am
> aware that these are speced by EcmaScript rather than WebIDL.)

That's definitely a reasonable precedent to consider.

FWIW:

We had a similar discussion in IE when deciding what attributes to give "const" properties. During Beta, we had the properties as configurable, but later changed our minds and made them fully "const" to emphasize the meaning of the term. 

So now, in IE9 RTM, we have:

>> Object.getOwnPropertyDescriptor(Node, "ELEMENT_NODE") 
{
	value : 1,
	writable : false,
	enumerable : true,
	configurable : false
}

OK, I will leave them non-configurable.

Adjusting resolution as the decision was to not make a change. (which I'm fine with for what it's worth).