es-discuss Digest, Vol 95, Issue 45

[Brendan Eich]

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