On Jul 11, 2011, at 4:18 PM, Brendan Eich wrote:
> So I think we took the wrong door here. Function.isGenerator by analogy to
> Array.isGenerator,
"... by analogy to Array.isArray", of course.
/be
> or an isGenerator export from "@iter" (equivalent semantically), is the best
> way.
>
>
>> However, methods are less desirable for class-like categorization because
>> they require an existence predicated call (f.isFoo && f.isFoo()) which
>> potentially leads to monkey patching Object.prototype
>> (Object.prototype.isFoo = function(){return false}). A truthy data property
>> is a plausable alternative that avoids the need for monkey patching, but it
>> doesn't work for value tests.
>
> Only if you know you have an object. If the predicate you need has signature
> "any -> boolean" then you want a function.
>
>
>> If a value tests can be recast as a class-like categorization then the data
>> property approach works for it.
>
> Right, but you can't "recast" for any type of value without writing a prior
> typeof conjunct. Or did you mean something else by "recast"?
>
>
>> Using an alternative prototype for all values in a "subclass" (eg all
>> generators) seems like a technique that might be plausible in situations
>> like this. It is essentially just a way to factor out of each generator the
>> storage of the true value for the isGenerator property. It doesn't require
>> the exposure of a separate Generator constructor.
>
> I think this misses the mark. Both Array.isArray in ES5 and
> Function.isGenerator in ES.next are testing nominal type tag. They are not
> testing some ad-hoc boolean "tag" that is not reliable and that can be forged.
>
>
>> We are trying to generalize to a pattern to apply to all (or at least most
>> isFoo) situations. Here is what we seem to have observed so far:
>>
>> A isFoo method works well for value classification for situations where you
>> will generally already know the "class" of the value.
>
> Agreed.
>
>
>> A independent classification function (perhaps hung from a constructor) may
>> be a good solution when value classification will generally be done in
>> situations where the "class" of the value is not predetermined.
>
> Agreed.
>
>
>> A truthy isFoo data property works will for class-like categorization as
>> long as all values that share the same prototype are considered members of
>> the same category.
>
> Disagree for the use-cases you applied this to. ES5 mandates a [[Class]]
> check for Array.isArray, and the impetus there was cross-frame Array
> classification based on nominal really-truly-built-in-Array type tag.
>
> Ditto for any isGenerator worth its name, that is, to the extent that the
> use-case for isGenerator does not simply want to test "is it an iterator
> factory", which could be a structural or duck-type test.
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
