Date.prototype mutable internal properties
allen at wirfs-brock.com
Wed Jul 6 12:06:22 PDT 2011
Would a better solution to simply say that Object.freeze also freeze the values of any internal properties. If there are exceptions we can explicitly identify them for the specific built-in objects. This seems like a better solution then changing a lot of built-in properties to being accessors.
Arguably, this was an oversight in drafting ES5.
Finally, please submit work items like this to bugs.emcascrpt.org as a bug against "Draft for 6th Edition". that way they won't get lost.
On Jul 1, 2011, at 6:01 PM, Mark S. Miller wrote:
> Thanks David,
> Yes, this is important. The way I noticed it is that the same issue came up for the FF implementation of WeakMaps <https://bugzilla.mozilla.org/show_bug.cgi?id=656828>. I will be proposing the to-be-fixed Mozilla API to the committee to become the new WeakMap proposal -- making it more consistent with Map and Set. But not at the upcoming meeting -- it's not on the agenda.
> In the meantime, <http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/ses/repairES5.js> repairs this and many other problems encountered in today's almost-ES5 implementations. Except for this issue with Date and WeakMap, all the other repairs in that file are spec non-conformances. See the kludges list at <http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js#989> for cross referencing between these repairs, various bug threads, and Sputnik/test262 test names.
> On Fri, Jul 1, 2011 at 12:28 PM, David Bruant <david.bruant at labri.fr> wrote:
> I just wanted to put on es-discuss the concern raised by Mark Miller 
> about mutable internal properties of Date.prototype and that it should
> be fixed in the next version of ECMAScript.
>  http://code.google.com/p/google-caja/issues/detail?id=1362
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss