Re: Setting this to null instead of throwing ReferenceError in a derived class' constructor

[Dmitry Lomov]

On Tue, Jan 20, 2015 at 11:25 PM, Brendan Eich  wrote:

> Ryosuke Niwa wrote:
>
>> Having said that, TDZ was introduced to give "let", "const", and alike a
>> sensible behavior as I understand it.  Since "this" was never defined by
>> "let" or "const", it seems a little arbitrary and inconsistent to make
>> "this" TDZ only inside a derived class's constructor.
>>
>
> It's not arbitrary as in a fair coin toss -- it's intentionally biased to
> catch errors. Using null or undefined would find fewer errors.
>
> I'm wondering whether other implementors feel the same pain. I mailed a
> few V8 folks asking them, maybe they'll weigh in.


I am not sure why that extra check is considered problematic
implementation-wise.
We have not yet implemented it in V8 (working on a patch right now!), but a
simple, even syntactic, analysis will probably eliminate checks in 90% of
real use cases. And normal function definitions need no extra checks.
Beyond that, 'this' binding is very similar to 'const' binding indeed, so
we hope that the same analysis we will apply for eliminating checks for
'const' and 'let' would apply for 'this' as well - at least that is the
plan.

Dmitry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Setting this to null instead of throwing ReferenceError in a derived class' constructor

[Andreas Rossberg]

On 20 January 2015 at 23:25, Brendan Eich  wrote:

> Ryosuke Niwa wrote:
>
>> Having said that, TDZ was introduced to give "let", "const", and alike a
>> sensible behavior as I understand it.  Since "this" was never defined by
>> "let" or "const", it seems a little arbitrary and inconsistent to make
>> "this" TDZ only inside a derived class's constructor.
>>
>
> It's not arbitrary as in a fair coin toss -- it's intentionally biased to
> catch errors. Using null or undefined would find fewer errors.
>
> I'm wondering whether other implementors feel the same pain. I mailed a
> few V8 folks asking them, maybe they'll weigh in.


Like with other occurrences of temporal dead zones, for the vast majority
of cases you should typically be able to tell statically (and easily) that
you don't need runtime checks.

But Dmitry is the one currently updating the implementation in V8, so he
might know more concretely.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Setting this to null instead of throwing ReferenceError in a derived class' constructor

[Brendan Eich]

Ryosuke Niwa wrote:
Having said that, TDZ was introduced to give "let", "const", and alike 
a sensible behavior as I understand it.  Since "this" was never 
defined by "let" or "const", it seems a little arbitrary and 
inconsistent to make "this" TDZ only inside a derived class's constructor.


It's not arbitrary as in a fair coin toss -- it's intentionally biased 
to catch errors. Using null or undefined would find fewer errors.


I'm wondering whether other implementors feel the same pain. I mailed a 
few V8 folks asking them, maybe they'll weigh in.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Setting this to null instead of throwing ReferenceError in a derived class' constructor

[Ryosuke Niwa]

> On Jan 20, 2015, at 11:34 AM, Erik Arvidsson  wrote:
> 
> How is this different from other TDZ (which happens with let and const 
> bindings)?

Indeed, there are many similarities and the same problem(s) do exist for those 
cases.  However, for now, we're implementing classes in WebKit at the moment so 
that's what we're focused now.

Having said that, TDZ was introduced to give "let", "const", and alike a 
sensible behavior as I understand it.  Since "this" was never defined by "let" 
or "const", it seems a little arbitrary and inconsistent to make "this" TDZ 
only inside a derived class's constructor.

> On Tue Jan 20 2015 at 1:52:14 PM Ryosuke Niwa  > wrote:
> Hi all,
> 
> We've been working on an experimental implementation of ES6 class syntax in 
> WebKit [1].  And we've found that keeping "this" in uninitialized state 
> inside a derived class's constructor is problematic.  It introduces lots of 
> branching around access to "this", which increases memory foot print and 
> startup time.  We can add a special optimizing compiler path to work to try 
> to eliminate these branches but that would only make the startup problem 
> worse and introduces undesirable complexities in our engine.
> 
> Would it be possible to change it so that "this" is set to null until super() 
> is called instead?
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=140491 
> 
> 
> - R. Niwa
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org 
> https://mail.mozilla.org/listinfo/es-discuss 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Setting this to null instead of throwing ReferenceError in a derived class' constructor

[Erik Arvidsson]

How is this different from other TDZ (which happens with let and const
bindings)?

On Tue Jan 20 2015 at 1:52:14 PM Ryosuke Niwa  wrote:

> Hi all,
>
> We've been working on an experimental implementation of ES6 class syntax
> in WebKit [1].  And we've found that keeping "this" in uninitialized state
> inside a derived class's constructor is problematic.  It introduces lots of
> branching around access to "this", which increases memory foot print and
> startup time.  We can add a special optimizing compiler path to work to try
> to eliminate these branches but that would only make the startup problem
> worse and introduces undesirable complexities in our engine.
>
> Would it be possible to change it so that "this" is set to null until
> super() is called instead?
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=140491
>
> - R. Niwa
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Setting this to null instead of throwing ReferenceError in a derived class' constructor

[Ryosuke Niwa]

Hi all,

We've been working on an experimental implementation of ES6 class syntax in 
WebKit [1].  And we've found that keeping "this" in uninitialized state inside 
a derived class's constructor is problematic.  It introduces lots of branching 
around access to "this", which increases memory foot print and startup time.  
We can add a special optimizing compiler path to work to try to eliminate these 
branches but that would only make the startup problem worse and introduces 
undesirable complexities in our engine.

Would it be possible to change it so that "this" is set to null until super() 
is called instead?

[1] https://bugs.webkit.org/show_bug.cgi?id=140491

- R. Niwa

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss