[Bug 12445] Consider making properties corresponding to IDL constants be configurable and unwritable

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12445

--- Comment #3 from Cameron McCormack <cam@mcc.id.au> 2011-04-08 18:04:57 UTC ---
(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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Friday, 8 April 2011 18:04:59 UTC