On Thu, May 24, 2012 at 4:50 PM, Erik Arvidsson <[email protected]>wrote:
> [snip] > > The problems with these is that no other dynamic language has these > kind of requirements. JS developers get by without them today. If we > designed a new language I think they would be nice features to have > (ahem Dart) but our goal is to improve ECMAScript and not replace it. > We should not try to make all languages fit into the same box. > > At this point I think it is up to Waldemar and supporters of his > requirements to come up with concrete proposals how these things can > fit into ECMAScript. (Thanks Russel for starting this thread.) > Yes, I would really like to see some more elaboration from him. I guess we'll have to wait for his return. One of the things that I was trying to show was that the max/min proposal is not future hostile, whether or not these things happen now, especially if it is not the default. I really just don't want classes to be blocked. - Russ > > On Thu, May 24, 2012 at 1:27 PM, Axel Rauschmayer <[email protected]> > wrote: > >> - One key question: Does a property declaration have to look declarative > >> in order to be used declaratively? You are saying no. > > > > > > I think a more declarative form could be added later, this is not future > > hostile to that. > > > > > > It looks OK to me. However, adding another form later seems like a bad > idea. > > > > What is currently here makes it so that any properties added during > > construction are non-configurable. Assuming the constructor gets run, and > > assuming properties are not added conditionally, guarantees can be made. > > > > > > Wouldn’t the instance be frozen? Then all properties would be > > non-configurable and non-writeable and the instance would not be > extensible. > > > >> - One could have `public foo = ...` as syntactic sugar for `this.foo = > >> ...`. But then the issue is whether `private` will ever be used in an > >> analogous manner (my understanding: no). > > > > > > Going with the max/min approach of tiny additions. The only addition > here is > > the const keyword in front of class. Big bang for the buck. > > > > > > I agree. > > > >> - Subtyping is going to be a bit tricky, because a constructor has to > >> behave differently if called from a subconstructor. > > > > > > This is covered in the original proposal, and I would have it work the > same: > > "During construction of an instance of a const class, the instance is > > extensible. Each public declaration adds a non-configurable, (possibly > > non-writable) data property to the instance. During constructor chaining, > > the [[Call]] method of the superclass constructor, even if const, does > not > > make the instance non-extensible. Rather, the [[Construct]] method of a > > const class makes the instance non-extensible before returning. An > instance > > of a non-const class which inherits from a const class is thereby born > > extensible unless the constructor makes it non-extensible by other means. > > Taken together, instantiating a const class must result either in a > thrown > > exception, non-termination, or in an instance of that class with the > public > > own properties declared within the constructor of that class." > > > > > > Nice. But it goes beyond a class declaration being syntactic sugar for a > > function (unless one introduces a way to specify [[Construct]]). > > > >> - I would love to have sealed instances. Those would be great for > catching > >> typos and performing shape-related optimizations. > > > > > > Yes, I think I might have specified this poorly. I'm seeking the same > > behavior as the original const class proposal. Instances would be > > non-extensible upon completion of construction. Nothing could be added or > > removed. Methods would be non-writable, but data would be. As I > indicated, > > private names can be used to protect against unwanted mutation. > > > > > > What function (or equivalent operation) would [[Construct]] apply to an > > instance after initialization? Object.seal() or Object.freeze()? > > > > -- > > Dr. Axel Rauschmayer > > [email protected] > > > > home: rauschma.de > > twitter: twitter.com/rauschma > > blog: 2ality.com > > > > > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > -- > erik >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
