Axel Rauschmayer wrote:
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).
It would be great if we could eliminate these predicates completely. How
often does the frame crossing problem matter in practice? It doesn’t
show up in non-browser environments, right?
But of course they do. Where do you draw your conclusion they don't?
There is vm module in node.js which runs code in different contexts;
webos-builtin nodejs uses context-per-module if I am not mistaken.
--
Dr. Axel Rauschmayer
[email protected] <mailto:[email protected]>
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
