David Bruant <mailto:bruan...@gmail.com>
January 20, 2012 12:51 AM
Le 20/01/2012 00:54, Brendan Eich a écrit :
That came up too: Object.type(x) would be the new typeof. But it will
take a while to get adoption, it's not built-in so monkey-patchable etc.
If Object.isObject has the second definition you showed, I don't think
an Object.type will be necessary, because every type will be testable
in one "instruction". Strings, numbers, booleans have typeof,
undefined and null are unique values (testable with ===) and
Object.isObject will test for ES5.1 - 8.6 definition of objects. It
won't be consistent as an Object.type method would be, but as far as
I'm concerned, I don't care.
We want "consistency along the major dimensions" for new features, if we
can. Having a bunch of isFoo predicates does not help switch on an
enumerated type value. On the other hand, we can't make a categorical
sum for all "types" or "classes" without a catch-call category within
which further subtype tests will be required anyway.
I think given existing practice we might justify
Object.typeOf(x) - typeof with Object.typeOf(null) == "null".
Object.classOf(x) - Object.prototype.toString.call(x).slice(8, -1)
using the original value of O.p.toString.
Comments?
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
