Setting this to null instead of throwing ReferenceError in a derived class' constructor
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.
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.
On 20 January 2015 at 23:25, Brendan Eich <brendan at mozilla.org> wrote:
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.
On Tue, Jan 20, 2015 at 11:25 PM, Brendan Eich <brendan at mozilla.org> wrote:
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.
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?