new instantiation design alternatives

Brendan Eich brendan at mozilla.org
Sun Sep 14 21:24:05 PDT 2014


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


More information about the es-discuss mailing list