12445 2011-04-07 23:59:18 +0000 Consider making properties corresponding to IDL constants be configurable and unwritable 2011-05-08 23:37:22 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified All All RESOLVED WONTFIX P2 normal --- 1 cam cam allen brendan erights jonas mike public-script-coord travil public-webapps-bugzilla oldest_to_newest 47245 0 cam 2011-04-07 23:59:18 +0000 We should maybe make properties corresponding to IDL constants be configurable, unwritable data properties, for consistency with the configurability of those for operations and attributes. 47270 1 brendan 2011-04-08 15:02:22 +0000 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 47274 2 erights 2011-04-08 17:23:19 +0000 (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 47276 3 cam 2011-04-08 18:04:57 +0000 (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. 47732 4 travil 2011-04-27 06:17:54 +0000 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 } 48336 5 cam 2011-05-08 23:09:29 +0000 OK, I will leave them non-configurable. 48337 6 jonas 2011-05-08 23:37:22 +0000 Adjusting resolution as the decision was to not make a change. (which I'm fine with for what it's worth).