Proposal: Symbol Linked to `typeof`

Augusto Moura augusto.borgesm at
Wed Jan 16 17:06:37 UTC 2019

I don't think string namespaced names are the right feature here

Namespaces are intended mainly to avoid conflicts with names when
sharing a global scope (like when using classpath in Java, or libs in
Javascript already solves this problems with modules, you can always
guard your code with instanceof and the right instance of your class,
you don't need "qualified names"
``` js
// flow.js
export class Flow {
``` js
// main.js
import { Flow } from './flow.js'; // we don't need namespaces, a "file
path" already resolves conflicts for us

const doSomething = (obj)  => {
  if (obj instanceof Flow) {
    // ...

You can also customize the instanceof operation with `Symbol.hasInstance`
``` js
class Flow {
  // Normally you would check the minimum contract required to any guard work
  // Probably bad idea to override in most of the cases
  static [Symbol.hasInstance](obj) {
    return '_flow' in obj;

// Note that the control is inverse to your proposal the Class
determines if a value is instance (this why it's static)
// Without altering `Flow[Symbol.hasInstance]` just expected objects
will pass the check in `doSomething`
doSomething({}); // doesn't work
doSomething({ __proto__: Flow.prototype }); // doesn't work
doSomething({ _flow: undefined }); // actually works

~string qualified names are so 20th century~

Em qua, 16 de jan de 2019 às 01:48, Randy Buchholz
<work at> escreveu:
> Right. Misappropriating a symbol corrupts its intent. As ES moves in a more towards a more “class-ish” feel, and people start writing more classes, a type/namespace system isn’t far behind. Implementing some symbols to support this helps drive some standard approaches and discourages symbol misappropriation.
> _______________________________________________
> es-discuss mailing list
> es-discuss at


Augusto Borges de Moura

More information about the es-discuss mailing list