new instantiation design alternatives

Andreas Rossberg rossberg at
Fri Sep 12 10:11:54 PDT 2014

Allen Wirfs-Brock <allen at> wrote:
> Mark, making such a change in a v2 would normally be considered bad practice
> in any OOP language I've worked with and probably would violate  most local
> style guidelines.  Subclassing for implementation sharing is at best gray
> box encapsulation.  The developer of a subclass who over-rides and/or super
> invokes methods of a base class has to know some things about the base.
> Ideally, those requirements are  captures in an explicitly documented
> subclassing contract provided by the base class' developer, but even if
> there is no such documentation there is always an implicit subclassing
> contract for every class that is used as a base class.

For better or worse, adding additional default arguments to existing
functions is common practice. And I don't even agree that it is
necessarily bad practice. There is no problem with it, except where
people pass redundant arguments to functions -- _that_ is bad
practice. The language shouldn't default to that practice itself.

> On Sep 12, 2014, at 8:26 AM, Andreas Rossberg wrote:
>> 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.

No, this doesn't have anything to do with types or overloading --
since it is just syntactic sugar for a (uniquely, syntactically
determined) explicit call, it is completely independent of such
concerns, and would work just as "well" in any of these languages. If
anything, such a feature would in fact be less problematic in such

> 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;
>     }
> }
> ``

I don't find this a convincing in favour of implicit argument passing,
rather the opposite. From my perspective, it unnecessarily obfuscates
what's going on.

But either way, I have a hard time believing that many programmers
with a background in the C syntax OO language family would expect the
above to invoke Point(x,y, color), as that's what no other language in
that family would do. So in addition to the refactoring hazard, I
expect that such code would rather be confusing for the majority of

Also, in practice it is rather rare that the parameter list of a
derived constructor happens to be an extension of the base one. Even
all other considerations aside, I don't see a good reason to optimise
for this minority case.


More information about the es-discuss mailing list