new instantiation design alternatives

Allen Wirfs-Brock allen at wirfs-brock.com
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:

```js
 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.

Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140912/4102a19f/attachment.html>


More information about the es-discuss mailing list