Jan 18 meeting notes
brendan at mozilla.com
Fri Jan 20 09:13:30 PST 2012
> David Bruant <mailto:bruant.d at 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.
More information about the es-discuss