new instantiation design alternatives

Brendan Eich brendan at mozilla.org
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, 
etc.

(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 `Base.call(this, ...)`. (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`:

https://gist.github.com/allenwb/53927e46b31564168a1d#calling-super-instead-of-invoking-super-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:

https://gist.github.com/allenwb/53927e46b31564168a1d#not-explicitly-assigning-this-in-a-derived-constructor

Whereas this:

https://gist.github.com/allenwb/5160d109e33db8253b62#a-derived-class-that-extends-the-behavior-of-its-base-class-constructor

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?

/be


More information about the es-discuss mailing list