Rick Waldron wrote:
Notably: Significant dissent on throwing exceptions for [iteration
protocol termination] control flow.
Counter-argument based on Python design and experience is that by far
the most uses of iterators never have to try/catch and simply use for-of
(for-in in Python) constructs: loops, comprehensions, generator
expressions. The StopIteration exception cannot escape such constructs
and won't be an issue in real debuggers (which must always provide
exception filters, including sane defaults).
BE cites years of experience with thousands of users via Python 2.5+ and
JS1.7+.
BE hierarchy of user population sizes related by >> ("much greater than"):
| group 1: users of iterators via for-of, no try-catch needed, no
problems |
>> | group 2: implementors of iterators who do not need to try-catch,
just throw StopIteration |
>> | group 3: implementors of task.js-like raw try/catch-StopIteration
coroutine libraries |
Some debate about ordering of group 2 vs. 3 sizes, LH cited C# different
experience but BE pointed to different design evolution and final design
state.
YK: (Question about use of in-band return?)
Disallows iterating over the in-band value. We've discussed this in the
past, want true OOB StopIteration to avoid this ad-hoc and uncheckable
restriction.
Discussion about protocol specifications, where precedent exists.
Rehashed Java (hasMore/getNext) and C# (Current/MoveNext) protocols
involving two methods, which costs more for implementors (groups 2 and
3, however ordered) and adds incoherence hazard (two methods get out of
sync; C# tries to mitigate common mistake with Java's, but still has
dual out-of-sync hazard to Java's).
MM agreed with BE that Python's is simplest given other constraints we
can't change, or "least bad".
Consensus holds in my view and if it didn't we couldn't hold it on a
great many things. I write these notes with some trepidation since
iteration protocols and exceptions for restricted control effects are
always going to excite debate. But full disclosure is best. These are my
missing notes for the meeting notes, which I thought got too sparse here.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
