Brendan Eich wrote:
I like Kevin's gist and want a private declaration too, both on its own
(block-scoped so private foo is const foo = new Name('foo')) and as a
special form in a class body, for body-scoped (fresh Name per class
expression or declaration evaluation) class-private instance variable
naming.
I don't think private in class-body is in any way special. As I see it,
it's the exactly same 'private foo' which declares foo locally visible
in the {} block with value of Name.create().
Seeing the other way, if you imagine 'private x' possible in object
initializer, so you can write:
let singletonCounter = {
private c,
@c: 0,
inc() { ++this.@c; },
val() { return this.@c; }
};
then 'private x' in class body is just straightforward syntactic mapping
of this 'private x' into class-body syntax.
None of this will kill us, max-min is just the smallest step, and one
complaint has been about "doing too little". But the bigger complaint I
saw was the one Waldemar raised (and has raised often): inability to
declare something like
sealed class Rect extends Shape {
new(x, y, w, h) {
super();
// initialize x, y, w, h instance variables
}
...
}
where, whatever the instance-property declaration and initialization
syntax, instance properties cannot be used before initialized, and the
instance is sealed by end of the new() method, *and* super() cannot add
expandos. Therefore, users of new Rect(...) can be sure they have an
object with only whatever Shape declared, plus x, y, w, h and any
prototype methods -- and no other properties. You get a runtime error if
you typo a property name.
Whether 'sealed' would be required or not, depending on what we do in
ES6 and later, I put it in to distinguish this Rect declaration from
typical examples we've seen that do not care about sealing or throwing
on typos.
Clearly some careful barrier specification would be required to satisfy
the no-use-before-init, no-expandos,
typos-on-unmapped(by-prototypes-if-not-instance)-properties goals.
The argument against max-min or other proposals that do not achieve
these goals goes like this: supporting sealed classes later will make
them less used or not used, when this is the sweet spot and
justification for classes over extended object literals. Therefore doing
only unsealed classes of the max-min or similar (per above) kind in ES6
does too little and makes a permanent attractive nuisance.
This is in addition to any future hostility (hard to prove there isn't
any, and I think Waldemar backed down on that objection). This is the
obstacle that I see. I think Allen's followup to the meeting notes
captures it, but I wanted to emphasize the sealed, no-expandos,
ivar-typo-checking goals.
Interesting. Thanks for information.
I hope Waldemar will correct me if I've misunderstood.
I'm not favoring anything by writing this, just trying to capture the
constraints we face in trying to find consensus.
/be
Herby
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
