using Private name objects for declarative property definition.

David Herman dherman at
Mon Jul 11 16:27:29 PDT 2011

> I'm not so sure about this now. I was just reviewing with Dave how the design evolved. We had Function.isGenerator, analogous to Array.isArray. For taskjs, Dave had thought he had a use-case where the code has a function and wants to know whether it's a generator. It turned out (IIUC) that what he really wanted (this will warm your heart) was simply the duck-type "does it implement the iterator protocol" test.

Right-- it was a poor initial implementation decision on my part; I shouldn't have done any test at all.

JJB had a different use case: for Firebug, he wanted the ability to check before calling a function whether it was going to have a different control-flow semantics. IOW, he wanted to be able to reliably reflect on values.

> On the other hand, code that wants to ask "is this *value* a generator?" may not have a-priori knowledge that the value is a function, so a class method such as Function.isGenerator wins.

Yeah, I think it's generally more convenient for type-distinguishing predicates to have input type 'any', so that clients don't have to do any other tests beforehand. That way, you can always simply do


instead of

    typeof x === "function" && x.isGenerator()

without knowing anything about x beforehand.

> So I think we took the wrong door here. Function.isGenerator by analogy to Array.isArray, or an isGenerator export from "@iter" (equivalent semantically), is the best way.

I agree.


More information about the es-discuss mailing list