Everybody should probably review
esdiscuss.org/topic/why-do-generator-expressions-return-generators where we
discussed this before.
It wasn't that there was necessarily anything bad about them, but there also
didn't seem to be a strong enough case made in that thread to justify the work
necessary to add them at this late data.
As you mention, there are issues with arrow functions not being constructors,
although it probably could be dealt with similarly to how generator
comprehensions are handled (generator comprehensions are essentially treated in
the spec. as a special form of generator function).
I also need to think a bit about whether there might be any this binding issues.
Allen
On Nov 12, 2013, at 4:37 PM, Brandon Benvie wrote:
> Currently, it's not allowed that arrow functions be generators. I did a bit
> of searching and couldn't find the original reasoning behind this. `*() =>
> {}` doesn't seem to be a problematic grammar since `foo * () => {}` isn't
> valid. The problem I do see is the mismatch between the generator class
> hierarchy and the fact that arrow functions don't have prototypes. I think
> this could be worked around somehow though.
>
> The use case I've started running into a lot is using Task.js with methods:
>
> ```js
> class Foo {
> foo() { //--> Promise
> return Task.spawn(*() => {
> const value = yield this.get(this.base + "/foo");
> if (yield this.bar(value)) {
> return true;
> }
> });
> }
>
> bar(value) { //--> Promise
> /***/
> }
>
> get(url) { //--> Promise
> /***/
> }
> }
> ```
>
> Without generator arrows, I'm back to using `var self = this` or
> `.bind(this)`.
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
