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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
