Kevin Smith wrote:
They're currently spec'ed to throw. I wouldn't change that for
ES6. It could change in the future.
Granted.
However, I don't think we should consider the design complete without
an answer to this question, regardless of what gets specced for ES6.
The answer may carry implications "in the large".
To illustrate my thinking, if we answer that new built-ins should
carry on the "factory when called" tradition of the pre-ES6 built-ins,
then we are setting a very strong precedent for how user classes ought
to behave. In that case, we can expect that users will want to
implement "factory when called" as a default behavior for their
classes. From that, we can foresee that the following pattern:
if (!new.target) return new Whatever(...args);
will become a kind of boilerplate. Obviously, we want to avoid
boilerplate as a general rule. When taken together, these
considerations might have a bearing on the overall design.
So I think it will be a good exercise to think a "few steps ahead" on
this question.
Agreed. If we believe most class constructors will construct when
called, we should bias the design that way. ASAP (which in my view
includes ES6).
If we want JS to impose a `new` tax on constructor calls, OTOH, for some
unstated (=== unknown) reason, let's be clear on that decision. If not
on the reason :-P.
(I'm really pleased with this direction in the subclassing design, btw!)
In general, I am too. In particular re: future-proofing and normal vs.
abnormal or happy vs.less-happy path design ergonomics (as I think you
agree), I'm not.
/be
Kevin
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
