using Private name objects for declarative property definition.

Brendan Eich brendan at mozilla.com
Mon Jul 11 16:22:10 PDT 2011


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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list