On Feb 14, 2012, at 5:48 PM, Mark S. Miller wrote: > On Tue, Feb 14, 2012 at 11:08 AM, Allen Wirfs-Brock <[email protected]> > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
