typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting
claude.pache at gmail.com
Sat Aug 3 14:20:36 PDT 2013
Le 3 août 2013 à 12:01, David Bruant <bruant.d at gmail.com> a écrit :
> For both null and the new value types, I'm still unclear on why could devs would choose something different than the default. I feel the incentives can only weigh in favor of keeping the default. I'm interested in what other devs think.
Having scanned my code, I can say that there is two cases where I regret to not have `typeof null === "null"`:
(1) One situation is when I want to distinguish many cases and do a `switch (typeof x)`. But for this case, most often, I'd like to "fix" not only `typeof null`, but also `typeof array` and `typeof date`...
(2) The other situation, more frequent, is when I want to distinguish a plain object from things like `null` or `false`. In this case `typeof obj === 'object'` has a false-positive, and I write either: `typeof x === 'object' && x`, or: `typeof x === 'object' // assert: x !== null` if the null value has been taken care before. It is really bad news that we risk to have `typeof x === "object"` by default when `x` is a value type, as it will invalidate my tests. Fixing `typeof` of old (null) and new value types would be a solution, but I'm rather definitely considering something like the defunct `Object.isObject()`. (As a side-note, I suggest `typeof uint64(0) === "number"` rather than `=== "object"` by default.)
But here is a potential good use of customisable `typeof`: I expect that sometimes you do not want to distinguish between int64, bignum, etc. (set typeof to "number" for all cases), but sometimes you do want to distinguish between them (set distinct typeof values). For this case, the scope of the modification should definitely be lexical, not dynamic.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss