using Private name objects for declarative property definition.

David Herman dherman at
Mon Jul 11 16:19:17 PDT 2011

>> 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.


More information about the es-discuss mailing list