new instantiation design alternatives

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Sep 17 10:45:25 PDT 2014


On Sep 17, 2014, at 6:17 AM, Herby Vojčík wrote:

> 
> 
> Claude Pache <claude.pache at gmail.com>napísal/a:
> 
> 
> For instance, if I wanted to support to be called through the legacy `SuperConstructor.call(this, ...args)` trick in addition to be new’d, I'd rather try the following:
> 
>    constructor(x, y) {
>        if (new^)
>            this = new super(x);
>        else
>            super.constructor(x);
>        this.y = y;
>    }
> 
> Oh, this is really bulky.

this isn't something that anyone will be coding every five minutes.  It's in only in a constructor of a derived classes and only if you want the constructor to have different behavior for [[Call]] and [[Construct]].  How often do you code such a constructor.

What we had been recommending under the current @@create-based design is that ES programmer code their constructors to only work as initialization methods (in other words to use the same logic whether [[Call]] or [[Construct]] invoked.  Because `super()` initialization was a [[Call]].  

I would still make the same recommendation. Code you constructors assuming they are [[Construct]] invoked (possibly by a subclass) and don't worry about [[Call]] behavior.  If you really want to do crazy things like some of the legacy built-in constructors you do need to make that discrimination, but in that case extra explicit logic is desirable.

> Makes me think of fixing it by some slight magic. Like, adding modifier to method deginition to say it is a constructor (new keuword before opening left brace) and keeping stack of new^s in thread-local storage which wull be used in new-tagged methods, even if [[Call]]ed.
> 
> But that is not a nice solution at all. :-/
> 
> The point here is that the purpose of the constructor method is not only allocation, but also (and primarily) initialisation.

And there really aren't complications for the allocation/initialization use case.  It is only when you call the [[Call]] use case that there are complications.  But rightfully so as you have to use one function body to do two different things.  But not a big deal, as this really should be rare.

Allen





More information about the es-discuss mailing list