On Feb 12, 2012, at 1:36 PM, Mark S. Miller wrote: > If the Date.prototype continues to be a valid Date object, which would be > unfortunate, it should at least be a valid Date object representing an > invalid unsettable date. I believe this is already what IE10 does. > > The invalidity isn't really necessary. What is necessary is that the internal > Date representation of this special object be unsettable, since it cannot be > made unsettable simply by freezing this object. Better would be to reform our > pattern that a built-in Foo.prototype is a valid Foo object, with all the > internal properties associated with a Foo, even though !(new Foo() instanceof > Foo). Fortunately, of the existing built-in primordials, it is only for Date > that this creates an unpluggable global communications channel. >
My current intent is to respecify the Date time value slot as a private named property rather than as an internal property. This will enable "freezing" of that property as well as enabling "subclassing" of Date. However, there is an issue. My current understanding is that we have agreed that Object.freeze and Object.seal will not reconfigure private named properties. Given our current stable of APIs, reconfiguring a private named property requires use of Object.defineProperty by someone who "knows" the private name. Do you think that Date will need an additional method that makes the time value immutable? Do we need to establish a convention for objects that want to enable public facing immutability requests? Note that immutability may not necessarily be the same thing as frozen or sealed. I can imagine situations (Date.prototype is a good example) where you would want to make an object "immutable" but still allow additions/modifications of methods or other new properties. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
