new instantiation design alternatives

Allen Wirfs-Brock allen at
Wed Sep 17 11:54:33 PDT 2014

On Sep 17, 2014, at 10:15 AM, Andreas Rossberg wrote:

> On 17 September 2014 19:04, Brendan Eich <brendan at> wrote:
>> 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.
> I agree. In fact, I don't see a reason to make it even that simple. My
> understanding was that there is wide agreement that invoking
> constructors without 'new' should be discouraged, and that functions
> behaving differently for Call and Construct are considered a legacy
> anti-pattern. In the light of that, I'm stilling missing the
> compelling reason to introduce new^ at all. In particular, since TDZ
> for `this` allows you to make the distinction fairly easily even
> without a new construct, if you are so inclined.

Boris covered the most important use case for this^.

The other one is self-hosting built-ins.  A lot of the cruft in the present ES6 spec. is about making sure that things like this ES5 code: = Date;
     console.log(typeof ((new Date()).foo()); //"string" according to ES5 spec.
     console.log(typeof( new Date()));           //"object" according to ES5 spec.

can continue to work the same in a self-hosted implementation of Data. Basically, just looking at the this value isn't sufficient to distinguish there two case in the self hosted world.  It helps a lot when you have to do this sort of crap to have an reliable way for ES code l to distinguish if they were invoked via [[Call]] or [[Construct]].  Since we need to provide access to the original constructor (Boris point) it's a nice bonus that we can use the same mechanism to make that distinction in the (hopefully very rare) cases where it is actually needed.


More information about the es-discuss mailing list