W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2011

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

From: <bugzilla@jessica.w3.org>
Date: Fri, 08 Apr 2011 17:23:20 +0000
To: public-script-coord@w3.org
Message-Id: <E1Q8FOy-00048T-6Y@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12445

--- Comment #2 from Mark S. Miller <erights@gmail.com> 2011-04-08 17:23:19 UTC ---
(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

-- 
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 17:23:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC