Allen Wirfs-Brock wrote:
the C/C# constructor header approach butts heads with other ES
features and isn't expressive for the sort of dynamic classes that ES
allows.
In terms of headbutting, consider
`constructor({a: x, b: y), [a1,a2,a3,...arest], c ) : super(??, ??)
{}// what do I put here to super call the constructor with only the
first two arguments)`
perhaps:
`constructor{a: x, b: y), [a1,a2,a3,...arest], c ) :
super(arguments[0], arguments[1]) {}`
but that means that the special header form must allow arbitrary
expressions. Are those expression in the parameter scope of the body
scope.
You meant "or", I'm sure. Kevin replied "yes" and "yes", which is funny,
but either way, parameters are in scope. That's a no-brainer. Why is
this a dilemma?
Most importantly, a single constrained expression isn't expressive
enough. The problem, is that a subclass constructor may need to
perform arbitrary compelx computations before super newing the its
base constructor. For example, consider a TypeArray subclass
constructor that filters various collections passed to to the derived
constructor to produce a simple list iterator that it passed to the
base constructor.
FWIW, I wouldn't want such a thing!
In the C++ family (Andreas is right, there's a history and lineage to
consider), the special head form may require you to keep it simple and
put any such conditioning in the base class, or an intermediary. This
doesn't bite back much.
Are you sure you've sorted use-cases by use-frequency?
The constrained super expression is a slippery slope that leads you to
a cliff. Better to go with the full generality and expressiveness of
the function body.
You need to demonstrate this, instead of assuming it.
Separately I agree `this = new super(x, y);` is just crazy long and
very likely to be left out in whole or in part (the `new`).
If left-out, programs will fail quickly and noisily (reference errors)
especially with the no auto super design alternative.
And then people will take TC39's name in vain. Every time.
We're trying to get this right, so arguing about design means minimizing
spank-the-user-to-write-boilerplate footguns. Saying "there's an error"
does not refute. There had better be an error! But can't we do better?
It's this explicitness that grows on you. The code actually says what
it means.
Classes as sugar, not as salt. The way this is headed, people will go
back to functions. I'm not kidding.
/be
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
