github at esdiscuss.org (2013-07-12T02:27:21.303Z)
On Mon 13 May 2013 19:24, Allen Wirfs-Brock <allen at wirfs-brock.com> writes:
> [`yield*` is] just a yielding loop over an iterator that for some reason
> was arbitrarily being restricted to being a generator.
I don't think the restriction you mention was present in the harmony
document, was it?
For what it's worth:
> If I'm implementing an iterator via a generator and I have to perform
> a inner-iteration over an contained iterable (for example, some sort
> of flattening operation) the way I code that inner iteration shouldn't
> depend upon whether or not the implementor of the inner iterable chose
> to use a generator rather than a stateful object as the iterator.
+1
> First why do we need `send` at all. Why not simply allow an argument to
> be passed to `next` (of course, it is already allowed) and leave it up
> to the generator implementation as to whether or not they pay any
> attention to it.
+1
> That leaves only `throw` as an issue. Personally, I'd just make it part
> of the Iterator interface and provide an Iterator abstract class that
> provides
>
> ```js
> throw(exception) {throw exception}
> ```
>
> as the default `throw` implementation so most iterator authors don't
> even have to think about it.
+1
On Mon 13 May 2013 19:24, Allen Wirfs-Brock <allen at wirfs-brock.com> writes: > [yield* is] just a yielding loop over an iterator that for some reason > was arbitrarily being restricted to being a generator. I don't think the restriction you mention was present in the harmony document, was it? For what it's worth: > If I'm implementing an iterator via a generator and I have to perform > a inner-iteration over an contained iterable (for example, some sort > of flattening operation) the way I code that inner iteration shouldn't > depend upon whether or not the implementor of the inner iterable chose > to use a generator rather than a stateful object as the iterator. +1 > First why do we need "send" at all. Why not simply allow an argument to > be passed to "next" (of course, it is already allowed) and leave it up > to the generator implementation as to whether or not they pay any > attention to it. +1 > That leaves only "throw" as an issue. Personally, I'd just make it part > of the Iterator interface and provide an Iterator abstract class that > provides > throw(exception) {throw exception} > as the default "throw" implementation so most iterator authors don't > even have to think about it. +1 Regards, Andy