Russell Leggett wrote:
However, that means if we take out arbitrary prototype properties,
we're back to a proposal which also hasn't reached consensus.
No proposal has. It's possible we'll get there either way, what is in
max-min or in Kevin's gists (not far off). Neither addresses the
sticking point that I heard in committee.
As for your fourth, most controversial point, separating call and
constructor would diverge from the existing pattern. Number() and new
Number() always call the same function.
That's one pattern. The other is Date() vs. new Date(), Object(otherObj)
vs. new Object(otherObj), and kindred warthogs.
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.
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.
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
