herby at mailbox.sk
Thu May 10 02:02:01 PDT 2012
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
> axel at rauschma.de <mailto:axel at rauschma.de>
More information about the es-discuss