Freezing private state (was: Rationale behind supporting "Invalid Date")

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Feb 14 11:08:28 PST 2012


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 






More information about the es-discuss mailing list