Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.

Overriding with methods and other edge cases #16

Closed
zenparsing opened this issue Oct 20, 2015 · 8 comments
Closed

Overriding with methods and other edge cases #16

zenparsing opened this issue Oct 20, 2015 · 8 comments

Comments

@zenparsing
Copy link
Member

Under the current proposal, declared property names are [[Set]] during instance initialization. This creates some interesting and perhaps unintuitive edge-cases.

First, if the field is overridden by a method:

class X {
  a = 1;
}

class Y extends X {
  a() { }
}

typeof (new Y).a; // "number"

The definition of a in the base class gets to overwrite the definition of a in the subclass.

Second, if the field is defined as an accessor pair in the base class:

class X {
  get a() { return "abc" }
}

class Y extends X {
  a = 1;
}

(new Y); // throws an error because there is no setter for "a"

It feels like something is going on here that shouldn't. Perhaps fields should not be allowed to shadow methods and vice-versa?

@zenparsing
Copy link
Member Author

(Edit: added the extends clause to an example above)

@michaelficarra
Copy link
Member

@zenparsing I'll be changing this behaviour very soon with an update to PR #6. Declared instance properties will be defined using [[DefineProperty]] on the instance, and class methods are defined on the prototype, so there shouldn't be anything surprising after that.

@zenparsing
Copy link
Member Author

Hey @michaelficarra !

Won't the first case still apply, though? The field declaration in the base class will end up shadowing the method declared in the subclass. I suppose it makes sense if you understand the mechanics, but the normal precedence of declarations is still inverted.

@michaelficarra
Copy link
Member

I think that's perfectly expected. Methods go on the prototype and fields go on the instance, so any fields will shadow prototype members.

@zenparsing
Copy link
Member Author

I disagree. : ) As a general rule, declarations in the base class (no matter what kind they are) shouldn't shadow declarations found in subclasses.

@michaelficarra
Copy link
Member

Well in general, all declarations in classes affect the prototype. This proposal changes that, adding a declaration that affects each instance, so general rules like the one you've mentioned will necessarily be violated.

@jeffmo
Copy link
Member

jeffmo commented Nov 10, 2015

@zenparsing:

class Base {
  constructor() {
    this.a = 1;
  }
}

class Child extends Base {
  a() { }
}

@jeffmo
Copy link
Member

jeffmo commented Aug 15, 2016

I agree this could be a hazard, but I don't think it's necessarily a new one (see my latest comment).
It appears to be a new variation on the normal hazards that can come with inheritance (in the absence of a type system).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants