On Jul 9, 2011, at 9:45 AM, Brendan Eich wrote:
> On Jul 9, 2011, at 8:48 AM, Brendan Eich wrote:
>
>> See above, there is nothing novel or evil in isName or isArray (another
>> example) isGenerator.
>
> Also the Proxy.isTrapping, which in recent threads has been proposed to be
> renamed to Proxy.isProxy or Object.isProxy.
>
> This is a fine point, but we may as well hash it out, and es-discuss is the
> best place: do we want Object.isFoo predicates, in spite of precedent such as
> ES5's Array.isArray (which I've whined about as redundantly and a bit
> misleadingly named, since its argument can be any value -- Object seems a
> better home, lacking a Value "class" built-in constructor in which to bind
> Value.isArray).
A consideration here is that whatever conventions we follow sets a precedent
for user written code. I don't think we want to encourage the addition of such
classification functions to Object or Object.prototype. So from that
perspective Array.isArray, Function.isGenerator, and Proxy.isProxy are better
exemplars than Object.isArray, etc.
Another consider is whether such classification schemes should use methods or
data properties. An instance side, isFoo() method to be useful generally will
also require the addition of an isFoo() method to Object.prototype while a
instance side-data property can be tested without augmenting Object.prototype
(({}.isFoo) is a falsey value). Also most user code classification schemes
will require some sort of instance-side tagging or testing to actually
determine whether the instance is in the category.
For those reasons, I think the best classification scheme is usually via an
instance-side public data property with a truthy value.
But there are some exceptions. For the legacy built-ins such as Array is less
risky from compatibility perspective to add properties to the constructor than
to the prototype. However, for new built-in this isn't an issue. Another
consider is meta layering: meta-layer functions shouldn't be exposed on
application layer objects. Proxy.isProxy is a good example. Proxy instances
operate as application objects in the application layer. The public face of
application objects shouldn't be polluted with a meta-layer method such as
isProxy.
>
> Back at the dawn of time, isNaN and isFinite as value predicates. Not
> relevant, since not type predicates, but worth a mention. ES.next adds saner
> (no argument coercion) Number.is{NaN,Finite} predicates, and Number.isInteger
> for testing whether a number is an integral IEEE 754 double.
>
> For ES.next, Function.prototype.isGenerator has been proposed (and
> implemented in Firefox 4 and up).
>
> Why not Function.isGenerator? Because the prototype method is more usable
> when you have a function in hand and you want to know whether it's a
> generator. If you have any value x, you'll need (typeof x === 'object' &&
> 'isGenerator' in x) guarding the x.isGenerator() call, but we judged that as
> the less common use-case.
Why not just make it a boolean-valued data property?
>
> Could be we were wrong, or that being consistent even in the
> hobgoblin/foolish sense is better. But Object.isGenerator crowds poor Object
> more.
>
> Notice how there's no need for Function.isFunction or Object.isFunction, due
> to typeof (function(){}) === 'function'. That's another dawn-of-time
> distinction that does not fit the primitiive types vs. object classification
> use-case I mentioned in the last message -- testing whether x is callable via
> typeof x === 'function', at least for native if not host objects, is the
> use-case here.
But this is a special case that does not extrapolate to other situations.
>
> Some of these questions are at this point more about aesthetics and
> Principles than about usability. And we have historic messiness in how things
> have grown.
In a utilitarian language like JS, usability and aesthetic considerations
should be closely linked and consistency is a significant usability factor. .
Principles are a way to get consistent application of such aesthetics .
>
> Given Array.isArray, perhaps we are better off with Proxy.isProxy. The case
> for Function.prototype.isGenerator hangs on usability, so I'd like to let the
> prototype in Firefox ride for a bit.
>
> If someone wants to propose a better, extensible and uniform system of type
> predicate naming, please do.
a start of one is above. The exceptions and special cases are where good
judgement is required.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
