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