Le 3 août 2013 à 12:01, David Bruant <[email protected]> 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.
—Claude
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
