new instantiation design alternatives
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,
(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`:
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:
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