Jorge wrote:
On May 9, 2012, at 11:43 PM, Brendan Eich wrote:
I think we should consider Object.isObject just because the typeof null change
replaced it, but 1JS killed that replacement. Also gives Object.isValue and
Array.isArray some company ;-).
Why not .isPrimitive()?
Could do that too, but Object.isPrimitive(x) would just be
!Object.isObject(x).
We've always been talking about primitive values and objects, isn't it?
Indeed, sometimes also with "reference type" for objects (not to be
confused with ECMA-262's "Reference" internal type).
Are we going to have RegExp.isRegExp() and Date.isDate() and Number.isNumber()
etc. too ?
I did wince a bit about ES5's Array.isArray -- perhaps since it takes
any x and tells whether x is an Array (from any window or frame)
instance, it should have gone on object. You're right that the
instanceof limitation motivating Array.isArray applies to these and
other built-in "classes" as well.
Do we just add 'em all, or try to add only the ones for which we have
enough experience to hope we're actually helping developers? How many
times have you wanted RegExp.isRegExp, say? The belief is that testing
for array-ness is more common. I don't have data, though, so I'm
uncomfortable with any "need-based" approach.
Adding lots of predicates is straightforward, but then the dialectic
requires us to wince at the sheer number of predicates (and the
redundant name stems), and try for something like what Axel suggested: a
do-it-all "type" or "typeOf" or "classify" API.
Comments welcome. I'm not sure what is best but lean toward predicates
as goods in themselves, even if not the complete solution (if there is a
complete solution).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
