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