typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Brendan Eich brendan at mozilla.com
Mon Aug 5 08:05:11 PDT 2013

Bruno Jouhier wrote:
> From a dev standpoint what we need is a clean API to discriminate 
> between types. Sometimes we want to discriminate between objects 
> (mutable) and values (immutable), sometimes between functions and non 
> functions, sometimes between numbers, strings and others, etc. And we 
> don't want to have to write an extra test to exclude null from objects.
> As we cannot break the existing typeof and its little warts,

While we can't change typeof null without opt-in, there's good reason to 
believe we can extend the co-domain of typeof:

* IE had non-standard results.

* Extant code does not therefore not exhaustively enumerate result value 

* Code does depend on the ==/=== invariant which motivates new typeof 
results for value objects (along with usability).

> could we introduce a new call, something like Object.typeInfo(x), that 
> would return a little hash like:
> { type: "int64", immutable: true, number: true, ... }
> { type: "string", immutable: true, number: false, ... }
> { type: "array", immutable: false, number, false, ... }

The first field is and should be what typeof returns.

What does "immutable" mean? We already have Object.isFrozen, etc., in ES5.

The "number" field is misleading in light of typeof 3.14 == "number".

> The idea it to have boolean flags like immutable/number/... to 
> categorize types. This way we can discriminate by testing a flag 
> instead of having to test complex combinations of typeof, 
> Array.isArray, etc.

Why would any code need to test combinations of those things to deal 
with value objects?

Array.isArray is irrelevant to value objects, but if you want typeof to 
return "array" for Array instances (how about subclasses of Array? How 
about array-likes?) that could be a separate opt-in. But those 
parenthetical questions need answers first.

There's no single typeof result that can tell all interesting facts 
about any value, especially composite values such as objects. OTOH there 
are good reasons to keep typeof working, and to minimize new APIs (as 
always) against *use cases*.

What are the use-cases -- let's say code examples from the field, or 
synthetic ones -- that you have in mind for your proposed API?


> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list