How to tell function and generator function apart?

Dean Landolt dean at deanlandolt.com
Wed Mar 4 02:56:12 UTC 2015


On Tue, Mar 3, 2015 at 5:26 PM, Domenic Denicola <d at domenic.me> wrote:

> As discussed previously such overloading is pretty bad. If someone creates
> a generator-returning function manually, instead of using a generator
> function to do so, they will start getting unexpected results from your
> library. You might think this is rare but it's actually pretty
> reasonable---consider e.g. `yourLibrary(transform(function* () { ... }))`
> where `transform` is a higher-order function which manually creates a
> generator based on its argument.
>
> An analogy would be that your and Dean's functions are similar to
> something like
>
> ```js
> function getFullName(person) {
>   if (person.constructor !== Person) {
>     // Do something else, e.g. `return person.toString()`
>   }
>
>   return `${person.firstName} ${person.lastName}`;
> }
> ```
>
> That is, now you have prohibited people from using { firstName, lastName }
> object literals, Person subclass instances, Dog instances, etc. That's very
> unfortunate practice. The same goes for generators.
>
>
FWIW the coroutine runner in my example is strictly a runner, not a wrapper
returning something analogous to an async function. I definitely see the
benefit of such a wrapper (and have been meaning to get around to adding
one), but the example I'd linked to is more like running coroutine
"program". I suspect there's still some benefit to this kind of style, if
just for simple debug cases, but with the presence of some kind of async
function wrapper, this "program" wrapper would really only need to support
generator functions, which means no need to bother w/ any
`isGeneratorFunction` nonsense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150303/ffe45423/attachment.html>


More information about the es-discuss mailing list