typeof null

Allen Wirfs-Brock allen at wirfs-brock.com
Wed May 9 19:53:27 PDT 2012


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. 

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