I am trying to override one method from the parent class, but there are some issues.
Below is the code snippet of my scenario which I am trying.
class Parent {
add = () => {
console.log('Parent method');
}
}
class Child extends Parent {
add () {
console.log('Child Method');
}
}
// Creating an instance
const child = new Child();
child.add();
It is calling the Parent method add as that is arrow function, Can someone explain why this is happening. If I make the parent function a simple javascript method then child is able to override.
Additonal Details :
I don't have access to Parent as it is part of library.
I can't make my child class method as instance properties (arrow function)
, the reason for being that there are further
specification written for child (child of child) and If we use arrow
functions we will not be able to call the super.
Child function name can't be renamed.
This is one of few reasons why arrow methods aren't convenient. They limit the ways in which a class can be extended and tested.
Class fields (which arrow methods are) are syntactic sugar for constructor code:
class Parent {
constructor() {
this.add = () => {...};
}
}
Only another arrow method can override parent arrow method, because they are defined in class constructor, not on class prototype:
class Child extends Parent {
add = () => {
/* no super.add here because add is not prototype method */
}
}
If super.add is intended to be used, a workaround is to store parent method:
class Child extends Parent {
superAdd = this.add;
add = () => {
this.superAdd();
}
}
Notice that since this is syntactic sugar for constructor code, the order in which superAdd and add are defined matters.
The parent add is an instance property, and it overshadows the child's class method, which is part of the instance's prototype. It's a bit hacking, but you can rename and delete the class property in the constructor:
class Parent {
add = () => {
console.log('Parent method');
}
}
class Child extends Parent {
constructor() {
super();
this.parentAdd = this.add;
delete this.add;
}
add() {
console.log('Child Method');
this.parentAdd(); // if you need call the parent's method
}
}
const child = new Child();
child.add();
Related
I use polymorphism with JSDoc to describe concrete implementations of some classes. Up until now I have been doing this with getters and setters; newly implemented public class fields can shorten this getter and setter boilerplate considerably.
My problem is described by the code snippet below. The value set in the constructor does not survive the redefining of the public class field. How can I redefine a public class field in an inheriting class and keep the value set in the super constructor? Is this a bug in public class fields?
class ThingHolder {
/**#type {notKnownYet}*/
publicFieldForThing
constructor(thing) {
this.publicFieldForThing = thing
//Do stuff for all thing holders
}
dropMyThing() {
//Throw not implemented
}
setThingField(thing) {
this.publicFieldForThing = thing
}
}
class RedThingHolder extends ThingHolder {
/**#type {RedThing}*/
publicFieldForThing
dropMyThing() {
//functionality for dropping a red thing with JSDoc niceties for RedThings
}
}
class BlueThingHolder extends ThingHolder {
/**#type {BlueThing}*/
publicFieldForThing
dropMyThing() {
//functionality for dropping a blue thing with JSDoc niceties for BlueThings
}
}
const redThing = {
colour: "red"
}
//Setting the thing in the constructor results in unextected behaviour
const redThingHolder = new RedThingHolder(redThing)
console.assert(redThingHolder.publicFieldForThing === redThing)
//Setting the thing through an inherited method after construction works perfectly fine
redThingHolder.setThingField(redThing)
console.assert(redThingHolder.publicFieldForThing === redThing)
Edit: This question was not about my motivations. Why do public fields behave differently to getters with regard to the prototype chain?
class Parent {
constructor() {
console.log("prop in instance during super: ", "prop" in this)
console.log("publicField in instance during super: ", "publicField" in this)
}
}
class Child extends Parent {
constructor() {
super()
console.log("prop in instance after super: ", "prop" in this)
console.log("publicField in instance after super: ", "publicField" in this)
}
publicField
get prop() { }
}
new Child
When you call the constructor of RedThingHolder class
new RedThingHolder(redThing)
the default constructor of RedThingHolder will pass the parameter redThing to the super class' constructor which will add a property publicFieldForThing on the newly created object.
Re-definition of publicFieldForThing in child classes overwrites the publicFieldForThing set inside the super class.
I feel like this is a bug and that the value should be retained
automatically.
Its not a bug and redefining a property with the same name will not retain a value because you are defining a field with a name that already exists on an object. Instead of retaining, it will overwrite the existing field.
Doing this
class RedThingHolder {
publicFieldForThing;
...
}
will overwrite the publicFieldForThing field with the default value of undefined.
How can I redefine a public class field in an inheriting class and
keep the value set in the super constructor?
You can set the publicFieldForThing in the child class constructor using the getter for publicFieldForThing defined in the super class.
class ThingHolder {
constructor(thing) {
this.publicFieldForThing = thing;
}
get publicField() {
return this.publicFieldForThing;
}
}
class RedThingHolder extends ThingHolder {
constructor(thing) {
super(thing);
this.publicFieldForThing = this.publicField;
}
}
const redThing = {
colour: 'red',
};
const redThingHolder = new RedThingHolder(redThing);
console.log(redThingHolder.publicFieldForThing === redThing);
Edit
Why do public fields behave differently to getters with regard to the
prototype chain?
getter/setters in ES2015's classes are added on the proptotype object whereas the public fields are added on the object itself.
In the code example you posted, prop is added on the Child.prototype whereas the publicField is like doing
this.publicField = undefined;
in the constructor of the Child class just after the super() call.
This is why "prop" in this inside the constructor of the Parent class returns true whereas "publicField" in this evaluates to true only inside the constructor of the Child class.
Why do arrow functions take precedence over function declarations in JavaScript Classes?
Example :
class Parent {
work = () => {
console.log('This is work() on the Parent class');
}
}
class Child extends Parent {
work() {
console.log("This is work() on the Child class ");
}
}
const kid = new Child();
kid.work();
The parent work() method fires in this example :
"This is work() on the Parent class"
I just want to understand WHY the arrow function always takes precedence in JS Classes, especially in regards to Inheritance and Polymorphism.
It is nothing to do with being an arrow function. It is taking precedence because it's a class field. Class fields are added as an own property of the instance while methods are added to Child.prototype.work. Even if you change it from an arrow function to a regular function, it will still execute the class field.
When you access kid.work, the order in which the property will be looked is
own properties, directly under kid object (It is found here)
Child.prototype.work
Parent.prototype.work
If still not found, it will be looked inside Object.prototype
class Parent {
// doesn't matter if it an arrow function or not
// prop = <something> is a class field
work = function() {
console.log('This is work() on the Parent class');
}
}
class Child extends Parent {
// this goes on Child.prototype not on the instance of Child
work() {
console.log("This is work() on the Child class ");
}
}
const kid = new Child();
// true
console.log( kid.hasOwnProperty("work") )
// true
console.log( Child.prototype.hasOwnProperty("work") )
// false
// because work inside Parent is added to each instance
console.log( Parent.prototype.hasOwnProperty("work") )
kid.work();
// How to force the Child method
Child.prototype.work.call(kid)
I have an inheritance like this:
class Parent {
some_object_property = ["some_object_property_depending_on_initialization"];
constructor() {...}
}
class Child extends Parent {
some_object_property = [...super.some_object_property, 'child_property']
}
Is there a way to let the Child inherit and extend object property some_object_property from the Parent?
I know I can achieve the end result through getter and setter. Is there a more direct way?
Did you mean this?
class Parent {
constructor() {
this.someProp = ['someprop test', 'something else'];
}
}
class Child extends Parent {
constructor() {
super();
this.someProp = [...this.someProp ,'added child prop'];
}
}
let myChild = new Child();
console.log(myChild.someProp);
It produces an error saying "super is not an identifier recognizable".
Yes, you cannot use super in a class field initialiser. Either put that line inside the constructor where it belongs (like in #DannyEbbers' answer), or just use the this keyword instead - it's just as good, no need to use super here:
class Parent {
some_object_property = ["some_object_property_depending_on_initialization"];
}
class Child extends Parent {
some_object_property = [...this.some_object_property, 'child_property']
}
this.some_object_property will refer to the instance property that was initialised by the parent constructor before you're overwriting it with a new value - it runs as if written inside the constructor.
Imagine I have 3 classes Child, Parent and Grandparent connected in hierarchy as follows:
class Grandparent {
set myField(value) {
console.log('Grandparent setter');
}
}
class Parent extends Grandparent {
set myField(value) {
console.log('Parent setter');
}
}
class Child extends Parent {
set myField(value) {
//I know how to call Parent's setter of myField:
//super.myField = value;
//But how to call Grandparent's setter of myField here?
}
}
How can I call Grandparent's setter of myField in setter of Child class?
I'm interested particularly in setter, not a method. Also it's much preferable to not make changes in Parent of Grandparent classes.
I don't see how that is possible using super because it references just Parent class, as well as using something like Grandparent.prototype.<what?>.call(this, ...) because I don't know what exactly to call in the prototype.
Does anyone have any suggestions for this case?
Thanks in advance!
using something like Grandparent.prototype.<what?>.call(this, ...)
You're on the right track there, you can access the setter method using Object.getOwnPropertyDescriptor:
Object.getOwnPropertyDescriptor(Grandparent.prototype, "myField").set.call(this, value);
There is a much easier way though: using the Reflect.set helper with a custom receiver:
Reflect.set(Grandparent.prototype, "myField", value, this);
This also has the advantage that it still works when Grandparent doesn't define a setter.
That said, I agree with #Dinu that there's probably a problem with your class hierarchy (or your general design, maybe you shouldn't even use classes or inheritance) when you need to do this.
You can use Reflect.set() with the optional receiver argument like this:
class Grandparent {
set myField(value) {
console.log('Grandparent setter');
}
}
class Parent extends Grandparent {
set myField(value) {
console.log('Parent setter');
}
}
class Child extends Parent {
set myField(value) {
Reflect.set(Grandparent.prototype, 'myField', value, this);
}
}
new Child().myField = 'foo';
If you don't have an explicit reference to Grandparent.prototype, you can use Object.getPrototypeOf(Object.getPrototypeOf(Object.getPrototypeOf(this))) instead which is obviously a lot less preferable. You could create a helper function though:
function getPrototypeOf (target, level = 1) {
return level > 0 ? getPrototypeOf(Object.getPrototypeOf(target), level - 1) : target;
}
and use getPrototypeOf(this, 3) in place of Grandparent.prototype to recurse up the prototype chain to the grandparent:
function getPrototypeOf (target, level = 1) {
return level > 0 ? getPrototypeOf(Object.getPrototypeOf(target), level - 1) : target;
}
class Grandparent {
set myField(value) {
console.log('Grandparent setter');
}
}
class Parent extends Grandparent {
set myField(value) {
console.log('Parent setter');
}
}
class Child extends Parent {
set myField(value) {
Reflect.set(getPrototypeOf(this, 3), 'myField', value, this);
}
}
new Child().myField = 'foo';
You might find a way to do it, but you shouldn't, not while you're doing class-based OOP, because it breaks the class-based model. In any sane environment, if Parent implements setX(), it expects that setX() behaves the way it defined it, in its context. It does not override setX() so that it can behave the way it did before.
So, if you're asking this, you either designed your class hierarchy wrong, or you actually need the prototype-based OOP.
If you write Parent, I assume what you are trying to obtain is an unmediated access to a certain property. The way to go is to define a method on parent/gradpa, like setXClean(), that is used as a celan setter. In this context, you probably want it to be protected and final on the grandparent.
The easiest way in my opinion, would be to just create another unique setter or method in the Grandparent class that sets myField.
class Grandparent {
set myField(value) {
console.log('Grandparent setter');
}
set grandParent_myField(value) { this.myField = value }
}
class Parent extends Grandparent {
set myField(value) {
console.log('Parent setter');
}
}
class Child extends Parent {
set myField(value) {
this.grandParent_myField = value
}
}
Another option would be to put super.myField in each setters body:
class Grandparent {
constructor() { this._myField = null }
set myField(value) {
this._myField = value
}
}
class Parent extends Grandparent {
set myField(value) {
super.myField = value
}
}
class Child extends Parent {
set myField(value) {
super.myField = value
}
}
Javascript ES6 ( node 8.4.0 and latest chrome and recent Firefox )
I expected
class Parent {
init(){
console.log("Parent init") ;
this._surname = "McClass" ;
}
constructor() {
console.log("Parent constructor") ;
this.init();
}
get surname(){
return this._surname ;
}
}
class Child extends Parent {
init(){
console.log("Child init") ;
}
constructor() {
super();
console.log("Child constructor") ;
this.init();
}
}
var child = new Child() ;
console.log(child.surname);
to give the following output;
Parent constructor
Parent init
Child constructor
Child init
McClass
(which is what comparable C++ code gives)
Alas, I got this ;
Parent constructor
Child init
Child constructor
Child init
undefined
Am I doing something wrong or is this the correct intended behaviour and if so how is it justified ?
EDIT;
See MinusFour's answer below on how to achieve what I was trying to do / expecting.
As to why the observed output is the "correct" behaviour and justified ;
As Bergi pointed out (in comments) all calls to object methods in js are effectively "virtual" (the last method of that name added to the object's prototype inheritance chain being the first found and hence executed). It turns out calls are still effectively virtual in a class construction context.
C++ does not apply virtual method behaviour during construction but then again Java does and you get the same output (as above) in comparable Java code so there is a precedent for the observed behaviour.
You could do:
Parent.prototype.init.call(this);
class Parent {
init() {
console.log("Parent init");
this._surname = "McClass";
}
constructor() {
console.log("Parent constructor");
Parent.prototype.init.call(this);
}
get surname() {
return this._surname;
}
}
class Child extends Parent {
init() {
console.log("Child init");
}
constructor() {
super();
console.log("Child constructor");
this.init();
}
}
var child = new Child();
To make sure it never gets overridden, but I would suggest you just not override it in the first place.
It is expected behaviour, just because it can be seen in established ES6 class implementations that follow the specs.
this refers to current class instance, which is an instance of Child in the case when Child is instantiated - even in Parent class, because there is only one instance, and it is instanceof Child.
If Child overrides the method, it's its responsibility to provide mechanism to call it. Considering that init follows some documented convention and is the place where class initialization happens in order to make constructor leaner and more testable, it is:
class Parent {
init(){...}
constructor() {
this.init();
}
...
}
...
class Child extends Parent {
init(){
super.init();
...
}
// optional, as long as `init` contains all init logic
constructor() {
super();
}
}
Which results in a sequence:
Parent constructor
Parent init
Child init
Child constructor
If init is supposed to work totally independently in both classes, it shouldn't be overridden. Methods should be named differently, like initParent and initChild. Or any other way to avoid naming collisions can be used, e.g.:
const init = Symbol('Parent init');
class Parent {
[init](){...}
constructor() {
this[init]();
}
...
}
...
const init = Symbol('Child init');
class Child extends Parent {
[init](){...}
constructor() {
this[init](); // totally independent method
}
}