using Private name objects for declarative property definition.
dherman at mozilla.com
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
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.
More information about the es-discuss