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