Comprende JS: typeof e instanceof

Parte XIII de la serie Comprende JS

Este es el ultimo tema que veremos en esta serie, pero no por ello menos importante y es que en Javascript como ya lo saben y dijimos en esta serie, es de tipos dinámicos lo que significa que al momento de asignar el valor a una variable es cuando determina el tipo de valor que tiene almacenado, por lo que existen operadores en JS, que nos ayudan a saber dicho tipo y para ello comenzamos con…

typeof

Consideremos el siguiente código.

Vemos que efectivamente typeof, nos devuelve el tipo de valor de cada variable, incluso podemos probar con valores no primitivos, es decir con objetos.

Hasta ahora muy bien todo, pero no todo es bello y perfecto, recuerda JS esta hecho por humanos…

Exacto…jajaja, bueno pues efectivamente typeof no es del todo confiable, en primer lugar tenemos que un valor null, que es el que regresa nuestra función fn(), el cual al evaluarlo con typeof, devuelve object, a pesar de que null, es un valor primitivo.

En la primeras implementaciones del motor de Javascript, la función JS_TypeOfValue, escrito en C, cuya función es la encargada de validar y devolver el tipo de dato, en sus condicionales solo contemplaba los siguientes tipos:

JSVAL_IS_VOID = valida si es undefined
JSVAL_IS_OBJECT = valida si es un object
JSVAL_IS_NUMBER = valida si es un number
JSVAL_IS_STRING = valida si es un string
JSVAL_IS_BOOLEAN = valida si es un boolean

Entonces todo aquello que no se contemplara es considerado un JSTYPE_OBJECT, y dentro de las validaciones de objetos hay una sub validación: ops->call != 0, es decir si iterando el objeto dentro de sus propiedades se encuentra un invocable, era considerado entonces una JSTYPE_FUNCTION.

Entonces null, al no tener una condición para el definida entraba en JSVAL_IS_OBJECT, sin embargo lo anterior es un error que quedo de la primera implementacion y cambiarlo seria muy peligroso o por lo menos es considerado un “Breaking change”, es por ello que se ha rechazado las proposals enviadas al gran team de Ecma TC39.

typeof y TDZ (Temporal Dead Zone)

Pero el anterior no el único factor que hace imperfecto a typeof, existe un factor mas que genera que typeof, no funcione adecuadamente, para ello consideremos el siguiente código.

Example from MDN Docs

Empecemos por definir TDZ (Temporal Dead Zone), las variables de tipo let, const y class, a diferencia de las var, se comportan distinto en el proceso del llamado “hoisting”, que vimos en los primeros episodios de esta serie, sabemos que esto sucede en la fase de creación del contexto de ejecución, el proceso consiste en poner todas las definiciones por encima de todo lo demás y con un valor undefined, pero let, const y class, no se declaran, quedando en una Zona Muerta Temporal, la cual por lo que si intentamos hacer referencia a esas definiciones, nos manda un error de referencia, al no encontrarlas.

Por ejemplo:

example from MDN Docs

El error en el ejemplo anterior, consiste en que existe un block scope dentro de nuestro loop for of, por lo que el scope chain encuentra n, antes de salir a buscar al outer environment, y que creen, exacto, es un let y para el momento en el que le hacemos referencian.a, no esta disponible, se encuentra en la TDZ y nos da error de referencia.

instanceof

Es importante no confundir typeof con instanceof, ya que instanceof valida sobre la cadena de prototipos “prototype chain”, de un constructor para ello utilizaremos un ejemplo que usamos anteriormente.

Pero al igual que typeof no es del todo fiable, veamos:

Example from Eric Elliot article

Resulta que lo que compara instanceof es baz.prototype === foo.constructor.prototype, lo que lo hace poco fiable, pero así las cosas.

Conclusión

Javascript tiene como todo lenguaje, errores, pues esta hecho por humanos, sin embargo, estas herramientas son de mucha utilidad, solo es cuestión de saber donde utilizarlas.

<< episodio anterior || episodio siguiente >>