using Private name objects for declarative property definition.

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jul 11 16:53:35 PDT 2011


On Jul 11, 2011, at 4:19 PM, David Herman wrote:

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

In fact, this is exactly how polymorphic reuse and extensibility occurs in dynamically typed OO languages. And, for the most part it actually works even in quite complete programs. You aren't assigning a universal semantics to a name in all programs but you are asserting a contextual semantics for this particular program. Even within a single program, different objects can assign complete different and unrelated meanings to isFoo as long as the different objects never need to both be processed by common code that does a isFoo test.

In practice, if such objects invalidly cross paths, any wrong answers from classification methods are usually easy to spot because they quickly lead to other dynamically detected failures.  Once that occurs  there typically are easily observable differences between the objects that make the problem easy to find.

Allen


More information about the es-discuss mailing list