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