On May 13, 2013, at 10:51 AM, Andy Wingo <wi...@igalia.com> wrote:
>> 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
Agree with the goal, as long as we can sensible achieve it.
>> 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
I'm fine with that; also fine with Andreas's "resume" name, which would help
with learnability if nothing else. (I have found I've had the most success
introducing beginners to generator functions by describing them as being like
regular functions that you can "pause.") Of course, the "next" name is more
appropriate for the for-of use case. (I'm laying down my bikeshed brush on this
one.)
>> 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
I aaaalmost agree. I want to agree. But part of the importance of the
structural type is that you don't have to use subclassing. You can't "mixin"
this default throw-through behavior with a base class. We could, of course,
offer a mixin function:
iterator({ next: ... })
But that sucks given that we expect most iterators will want the default
behavior. Alternatively, we could make the .throw method optional and have it
automatically throw-through. I was worried at first that that might be creepy,
but really it's kind of sensible. It's an optional iterator method for the MOP
that has a sensible default behavior.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
