I have the following class that extends the built in data type Set. It adds a little bit of extra functionality by checking that every element that wants to be added to the set conforms to the type specified as the first parameter of the constructor. It does this silly "type checking" through the typeof operator. I save the type of the Set in a private field. If I try to override the .add() method so that it also does this little type checking, I get an error stating Uncaught TypeError: can't access private field or method: object is not the right class
class TypedSet extends Set {
#type;
constructor(type, elements) {
if (elements && !elements.every(e => typeof e === type)) throw new TypeError(`Not all elements conform to type t->${type}`)
super(elements)
this.#type = type
}
add(e) {
return typeof e === this.#type
? super.add(e)
: new TypeError(`Type of element e does not conform to type t: ${this.#type}`)
}
}
const s = new TypedSet('string', ['hello', 'world'])
s.add('!')Why do I get that error if i try to access the private field -- the one I declared in the subclass -- in the overriden .add() method ? If I rename the .add() method to something like .typeAdd() referencing the private field doesn't throw an error
The problem is that super(elements) will call the add method to add the elements to the set1. At that point, your subclass constructor did not yet create the field (this.#type = type).
As a workaround, you can use
class TypedSet extends Set {
#type;
constructor(type, elements) {
super()
this.#type = type
for (const e of elements ?? []) {
if (typeof e !== type) throw new TypeError(`Not all elements conform to type t->${type}`)
super.add(e) // or this.add(e)
}
}
add(e) {
return typeof e === this.#type
? super.add(e)
: new TypeError(`Type of element e does not conform to type t: ${this.#type}`)
}
}
const s = new TypedSet('string', ['hello', 'world'])
s.add('!')1: Calling an overrideable method from the constructor is usually considered an antipattern, for exactly the reason that your use case doesn't work. No idea why ECMAScript did specify this regardless. On the other hand, it's also not recommended - even if possible - to extend builtin classes, there are too many surprises such as this. Composition is usually a better approach.