new instantiation design alternatives
allen at wirfs-brock.com
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 mozilla.org> 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.prototype.foo = 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