new instantiation design alternatives

Allen Wirfs-Brock allen at
Fri Sep 12 09:38:14 PDT 2014

On Sep 12, 2014, at 8:26 AM, Andreas Rossberg wrote:

> Thanks Mark, this was exactly my concern as well. In general, it is
> bogus to assume that the parameter lists of a base and a derived
> constructor bear any relation. And even if they happen to do so today,
> they might no longer tomorrow, which your example demonstrates quite
> well. So just silently forwarding an argument list nilly-willy is
> broken.
> I think it's fine to have a default "new super" call, but only with an
> empty argument list. That would also be more in line with what other
> languages do.
Other languages that do that are predominately statically-typed OO languages with static overloading.  In that situation, the most generic choice is non-parameters as some overload has to be chosen for the implicit call site.

But for JS, which does have a static overload selection requirement, we have other alternatives and the no-argument choice seems highly error prone.

Consider Mark's example again.  If developers are saying they would prefer to write:

 class ColoredPoint extends Point {
    constructor(x, y, color) {
        this.color = color;

Then some will do it (regardless of the actual semantics) and they will silently get an instance without x or y properties.  That is pretty clearly not their intent. 

I think this is a much bigger error hazard then the v2 refactoring issue that Mark is concerned about.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list