using Private name objects for declarative property definition.

Allen Wirfs-Brock allen at
Mon Jul 11 12:40:32 PDT 2011

On Jul 11, 2011, at 10:41 AM, Brendan Eich wrote:

> On Jul 11, 2011, at 10:25 AM, Allen Wirfs-Brock wrote:
>> Certainly there is no need to add any new globals to support a distinct prototype for generator functions. Strictly speaking there wouldn't even have to be a property on Function to access it as it would be a built-in object that is accessed internally when a generator is created.  However, I do think it would be useful make it accessible via something like Function.generatorPrototype.   I don't see that adding such a property as undesirable pollution.
> We're still trying to get isFoo conventions in order. Why add another (first-of or one-off) built-in prototype convention?
> I'm going to stick with YAGNI and when in doubt, leave it out. Generators win to the extent that they are functions with the least shallow continuation semantics on top that work.

Let's try to back out of the brambles a bit:

On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:

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


>> 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").

isGenerator is essentially a value test rather than class-like categorization.  Methods work well for this because a method can dynamically inspect the value being tested in order to make the determination.

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.

If a value tests can be recast as a class-like categorization then the data property approach works for it. 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. 

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.
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.
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list