> 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 isGenerator(x) 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. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss