On Sep 17, 2014, at 10:15 AM, Andreas Rossberg wrote:
> On 17 September 2014 19:04, Brendan Eich <bren...@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.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
