I think it is impossible to achieve Waldemar's goal with syntactic
sugar only. I also don't think that is reason enough to block ES6
classes. The requirements he wants cannot be expressed with ES5
semantics.
The big issues Waldemar wanted were (as far as I remember):
1. Reading a non existent property should throw:
const class C {}
const c = new C;
console.log(c.foo); // throw to catch typos
This is a major change in semantics of JS and it was shot down for ES5
strict so I don't think it has any chance of getting accepted ever.
2. No way for an object to escape the constructor before the
constructor was "done":
const class C {
constructor() {
this.x = doSomething(this); // oops, this.y is not yet initialized
this.y = doSomethingElse();
}
Alternatives here include read barriers but that also requires
declarative instance properties so we know ahead of time what to
poison.
3. Shape guarantee:
const class C {
constructor() {
if (Math.random() < .5)
this.x = true; // Half of the times there will not be an x property.
}
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.)
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
