Proper handling of super() call semantics #186

Open
nene opened this Issue Sep 29, 2016 · 2 comments

Projects

None yet

2 participants

@nene
Collaborator
nene commented Sep 29, 2016

Lebab will currently produce invalid ES2015 code for super():

  • super() must be called before any references to this. The following code will fail:

    constructor() {
      this.age = 10; // ReferenceError
      super();
    }
  • super() must always be called from subclass constructor. The following code will fail:

    class Foo extends Bar {
      constructor() {
        this.age = 10; // super() not called
      }
    }

I basically see two solutions:

  • refuse transforming code like this, display a details error message about what's wrong, so user can correct it and then try running Lebab again.
  • do transform the code, but produce an additional warning.

I'm leaning towards the first approach as that's what Lebab has been doing in all other transforms so far.

@nene nene referenced this issue Sep 29, 2016
Closed

Support extending classes #33

4 of 6 tasks complete
@apexearth
Contributor

I was looking at this a few weeks ago and it seemed that if any pathway of the code referenced this prior to executing super(), the reference error would occur. I believe that is the extent of the problem.
Do you see any more complexity in the problem beyond that?

I also agree with your first approach.

@nene
Collaborator
nene commented Sep 30, 2016

No, I think that's it. I was wondering whether one could define a function internally using this that you could call before super() - but I think it's not possible. Well... you could call functions that use this before super(), but the this would be referencing something else than the current object.

We also need to watch out for false-positives. The following code is valid:

constructor() {
    var foo = function() {
        return this;
    };
    super();
    foo.call(this);
}

But this is not:

constructor() {
    var foo = () => {
        return this;
    };
    super();
    foo();
}

Which I think simply comes down to that we should not look for this inside normal functions - only inside arrow-functions.

@nene nene referenced this issue Jan 16, 2017
Open

Class extends #209

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment