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

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Feb 14 18:22:23 PST 2012


On Feb 14, 2012, at 5:48 PM, Mark S. Miller wrote:

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

Specifying the attributes works for Date.prototype, but programmer might want to make the private time value property of some other Date objects be non-writable, non-configurable. Making the private name of the property problem seems like an undesirable way to enable that. 

>  
> 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 this case I actually meant sometime weaker.  I mean that the "value state" of the object can not be modified. For example, like the string value state of an String object or the number value state of a Number object. "Public" properties can still be added to such objects.  (Perhaps all properties "frozen" but the object is still extensible is a close to what I have in mind.) What exactly constitutes the "value state" of any particular object will vary according to what is being modeled by the object.  However, I suspect ES style will move in a direction where often such "value state" is represented using private named properties.

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

I assume some of the difficulties relate to specific invariants you might want to apply to all of your immutable objects.  I'm not thinking of any such invariants, instead I would view the meaning of what I mean by immutability to be defined by each object abstraction.

Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120214/000f2499/attachment.html>


More information about the es-discuss mailing list