new instantiation design alternatives

Brendan Eich brendan at
Wed Sep 17 10:04:07 PDT 2014

I agree with Domenic that any derived-class constructor that needs to 
allocate with specific arguments *and* that must distinguish new'ing 
from calling should have to write an if-else. That's a hard case, EIBTI, 

(Allen: well-done on that aspect of the design, BTW. `new^` is growing 
on me, too.)

Rick Waldron wrote:
>     The more pressing ergonomic question is whether `this = new
>     super(...)` is too much. I think it's fine, especially in
>     comparison to `, ...)`. (For those counting
>     characters, the score comes down to how long your superclass name
>     is, and I'd wager most are longer than the five characters
>     required for the new syntax to start winning.)
> Not to simply dogpile here, but I agree with Domenic, regarding `this 
> = new super()`. I'll add that this form has high "teachability" value: 
> the syntax expresses the semantics in a nearly "literary" way, ie. 
> "Allocate _this_ subclass instance with an _new_ instance of its 
> _super_ class. Then proceed with initialization".

Check me here, should if you disagree: the hazard that remains is when 
Java-trained programmers call super without new, thinking that's how to 
call the base constructor in all cases. They'll get spanked with a 
reference error when testing the constructor invoked with `new`:

I'm on board with teaching around this hazard. (You know me, always 
willing to spank Java-heads a little :-P.)

What about the big choice between implicit vs. explicit-only base 
constructor calling? This seems like a bug to me:

Whereas this:

seems winning, given classes as sugar, DWIM and DDWIDM. This is option 
1, not option 2.

Sorry for not tracking better: Is the capability leak a fatal objection 
to option 1?


More information about the es-discuss mailing list