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

Mark S. Miller erights at google.com
Tue Feb 14 17:48:43 PST 2012


On Tue, Feb 14, 2012 at 11:08 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:

>
> 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.


Yes.



> 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?


That would work. It would also work to expose this name directly, so that
it is in effect not private within its context. For this particular case,
another possibility is perhaps lighter weight. Once you explain the
internal property as a privately named property, you can explain that all
the internal property of Date.prototype is a non-configurable non-writable
privately named property with value NaN, as if by Object.defineProperty.



> 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.


I would like to see general support for immutability for many reasons. But
you seem to mean something different. I've been using immutable to mean
approximately "transitively frozen", so it would be stronger than "seal" or
"freeze".

I have postponed voicing my desire for general immutability support since
it raises a variety of hard issues which would definitely exceed our budget
for ES6. Even if above you mean general support only for "freezing"
privately named properties, I expect many of these hard problems to arise
as well. But yes, we should start talking about it.


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120214/a7357a32/attachment-0001.html>


More information about the es-discuss mailing list