new instantiation design alternatives

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


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

>
>
> On Sep 17, 2014, at 6:40, "Kevin Smith" <zenparsing at gmail.com> 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
> `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".

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140917/e4507997/attachment.html>


More information about the es-discuss mailing list