new instantiation design alternatives

Rick Waldron waldron.rick at
Wed Sep 17 08:02:41 PDT 2014

On Wed, Sep 17, 2014 at 9:59 AM, Domenic Denicola <
domenic at> wrote:

> On Sep 17, 2014, at 6:40, "Kevin Smith" <zenparsing at> wrote:
>>      constructor(x, y) {
>>         if (new^)
>>             this = new super(x);
>>          else
>>             super.constructor(x);
>>         this.y = y;
>>     }
>>  The point here is that the purpose of the constructor method is not
>> only allocation, but also (and primarily) initialisation.
>  Yes - you are right.  And I think we can safely assume that users will
> refuse to write such boilerplate.
>  That seems fine. Enabling different behaviour for called vs. constructed
> should only be used to explain the builtins; user code should not do so
> themselves. So it makes sense to me that those trying to do that would get
> "punished" with having to type more.
>  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".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list