>> Adding a non-enumerable Array.prototype method seems doable to me, if the
>> name is clear and not commonly used.
>
>
> We can probably still add Array.prototoype.isArray if that would help to
> establish the pattern. Document as being preferred over Array.isArray
This doesn't make sense to me. Let's say I have a variable x and it's bound to
some value but I don't know what. That is, it has the type "any." I could check
to see that it's an object:
typeof x === "object"
and then that it has an isArray method:
typeof x.isArray === "function"
but how do I know that this isArray method has the semantics I intend? I could
check that it's equal to Array.prototype.isArray, but that won't work across
iframes.
IOW, I can't call x.isArray() to find out what I want it to tell me until I
already know the information I want it to tell me.
Alternatively, if I expect isArray to be a boolean rather than a predicate, I
still don't have any way of knowing whether x is of a type that has an entirely
different semantics for the name "isArray." It's anti-modular to claim a
universal semantics for that name across all possible datatypes in any program
ever.
These "static" predicates (which are just glorified module-globals) intuitively
have the type:
any -> boolean:T
(I'm using notation from SamTH's research here.) This means a function that
takes any value whatsoever and returns a boolean indicating whether the result
is of the type T. Because they accept the type "any", it doesn't make sense to
put them in an inheritance hierarchy. It makes sense to have them as functions.
Since globals are out of the question, in the past they've been made into
"statics." But with modules, we can actually make them functions in their
appropriate modules.
Dave
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
