using Private name objects for declarative property definition.

Brendan Eich brendan at mozilla.com
Sun Jul 10 18:58:32 PDT 2011


On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:

>>> However, arguably Array.isArray really should have been Array.prototype.isArray.  We treated as a case 2 from above.  May we really didn't need to, but that's water over dam.  I don't think we should use it as precedent for more greenfield situations.
>> 
>> First thought: Crock sold us on reformed Number.is{NaN,Finite} along with new Numer.isInteger. We can "do both" and correct course for the long run, perhaps: Array.isArray and Array.prototype.isArray. But first we should settle the data property vs. method issue.
> 
> yes.  I wonder if isArray and isInteger are different kinds of categorizations ("class" based vs value based) that perhaps should have distinct naming conventions.

The isFoo predicate convention is used variously in other languages. Kind of like foop in Lisps. I would not tax name length just to distinguish these cases, or others (ontology fanatics will soon be splitting sub-cases of "value-based").


>>> But f the method implementation is simply going to be return true or return false why do yo need to call it at all?
>> 
>> The general case is an optional method, a notification hook call-out or some such.
>> 
>> You're right that for object detection the method call seems a waste. We could have made Function isGenerator a non-writable, non-configurable, and non-enumerable boolean-valued data property.
>> 
>> But, then it would be an instance property, which burns storage (the shape or hidden class sharing is not the issue, the true or false value slot is); or else an accessor on Function.prototype, which is about as costly as a method in implementations. Users testing it would not have to write (), your point. That wins. But otherwise it's a wash.
> 
> Why not a non-writable,non-enumerable non-configurable data property on Function.prototype.

We're talking about isGenerator, right? There is no Generator constructor, no shadowing opportunity. Function can create a generator if yield occurs in the body string.

Here's a reason to prefer a method, at least one method per "feature": you can then object-detect the method without having to autoconf-style try/catch a generator in eval or Function. Just "if (Function.prototype.isGenerator)" or (shorter, works as noted) "if (Function.isGenerator)" to guard code (perhaps a script injection) that depends on generator support.

/be


More information about the es-discuss mailing list