typeof null

Herby Vojčík herby at mailbox.sk
Thu May 10 02:10:20 PDT 2012

Allen Wirfs-Brock wrote:
> On May 9, 2012, at 4:08 PM, 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?
>> I see several possibilities: - Make instanceof work correctly with
>> objects that have crossed frames. - Introduce a binary predicate,
>> e.g. likeInstanceOf that correctly handles cases where the lhs and
>> rhs come from different contexts/frames.
> The reason there will never be a single solution to these issue is
> that desirable behavior varies depending  upon what the programmer is
> trying to accomplish. Just using (possibly cross-frame) arrays an an
> example.  What is the programmer really asking when they say "is this
> object an Array".  Do the need to know whether it has array indexed
> properties and a length property? Do they need to know where it
> maintains the special Array length invariant? Do they need to know
> whether it implements it has properties that implement the array
> extra methods? Do they need to know that in inherits from the
> build-in array prototype object?  Or, do they just need to know
> whether they should serialize the object using [ ] instead of {  }
> notation?
> The last one was the situation that jason2.js ran into WRT
> cross-frame arrays and it provided the use case that lead to
> Array.isArray. But it isn't clear that was the best possible
> solution.  Another solution might have been to add a serializeAsArray
> property to Array.prototype.  That would work cross frame and it
> would have made it easier to for programmer to define there own
> internal abstractions that would also serialize using [ ] notation.
> Whenever anybody says they need to do a type test (or instanceof
> test) we need to ask them: Why? What is it you really need to know.
> Smalltalkers learned fairly early that type/class testing was an
> anti-pattern. It makes code brittle and difficult to fix or extend.

Yes, smalltalkers frown upon isKindOf: which is like JS instanceof. But 
they have their isNumber, isInteger, isNil, isWhateverElse methods. At 
least for "built-ins" they can be pretty sure than sending isInteger 
returns true for any object that pretends to be integer, even in case it 
would be a proxy from different Smalltalk (I am trying to make a case 
analogous to cross-frame). So for these "built-in" types, checking that 
works cross-frame should probably be there (akin to Array.isArray).

> I'm not sure what a cross-frame instanceof test (that didn't always
> return false) would mean. I understand why json2.js thought it needed
> to do a cross-frame isArray test.  I would like to understand other
> real use cases where cross-frame type testing is needed. Does anybody
> have any?
> Allen


More information about the es-discuss mailing list