Tengo la siguiente clase que amplía el conjunto de tipos de datos integrado. Agrega un poco de funcionalidad adicional al verificar que cada elemento que desea agregarse al conjunto se ajuste al tipo especificado como el primer parámetro del constructor. Hace esta tonta "comprobación de tipo" a través del operador typeof . Guardo el tipo del Conjunto en un campo privado. Si trato de anular el método .add() para que también realice esta pequeña verificación de tipo, aparece un error que indica 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('!') ¿Por qué recibo ese error si trato de acceder al campo privado, el que declaré en la subclase, en el método .add() ? Si cambio el nombre del método .add() a algo como .typeAdd() que hace referencia al campo privado no arroja un error
El problema es que super(elements) llamará al método add para agregar los elementos al conjunto 1 . En ese momento, el constructor de su subclase aún no había creado el campo ( this.#type = type ).
Como solución alternativa, puede utilizar
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: llamar a un método reemplazable desde el constructor generalmente se considera un antipatrón, exactamente por la razón de que su caso de uso no funciona. No tengo idea de por qué ECMAScript especificó esto independientemente. Por otro lado, tampoco se recomienda, incluso si es posible, extender las clases integradas, hay demasiadas sorpresas como esta. La composición suele ser un mejor enfoque.