Andreas Rossberg wrote:
On 12 June 2013 19:51, Brendan Eich<[email protected]> wrote:
The @iterator part of the iteration protocol is not about coercion or types
at all. It is a "pattern" for getting or creating a usable iterator from an
object.
You are entitled to call it what you think is best, of course, but in
the current state of affairs, implicit coercion is the only thing
@iterator actually gives you. Simple test: if you removed it from the
picture (in favour of for-of just accepting iterators) that would be
the only thing you'd lose.
Your rebuttal leaves it a matter of indifference what either of us calls
it, but the "implicit" part is not at issue. The "coercion" is. You are
taking a typed point of view, wanting something even most type systems
can't express: that a fresh iterator is either always or never returned.
I think that's simply not useful based on copious experience in Python
and JS.
On 12 June 2013 20:14, Brendan Eich<[email protected]> wrote:
Claude Pache wrote:
Le 12 juin 2013 à 18:14, Andreas Rossberg<[email protected]> a écrit :
On 12 June 2013 14:12, Claude Pache<[email protected]> wrote:
<snip>
On the other hand, I see a small advantage of the "weird" requirement
for iterators to be iterables themselves: It allows to discriminate between
true iterators and merely "nextable" objects.
And in the spirit of "duck typing", why would you want to do that?
Just so that an error is surely thrown in case I feed a for/of loop with a
non-iter{ator|able}. In the spirit of duck-typing, I consider that "having
an `@@iterator` method" is a more robust check than "having an `@@iterator`
or a `next` method". Not a big deal, however.
I think it is a medium-sized deal :-).
First, it's conceptually cleaner to have one symbol-named property test than
two, symbol and then string name fallback.
Second, it is indeed more robust in this instance: 'next' is a common name,
with many contextual meanings and likely uses.
I am a bit surprised to see you on the opposite side of the "duck
typing" fence all of a sudden. ;)
Please, no false dichotomies. I wrote on this thread yesterday that
duck-typing via a symbol is more robust than via a string-name. It's
still duck typing, though.
And
how do you want to treat an iterable with a 'next' method, but whose
@@iterator method does not return 'this'? Is that a "true" iterator?
(The fact that such a beast can even exist shows how fuzzy those
notions are.)
You're right, but I don't expect to encounter such a beast often.
Concretely, they are buggy objects that would not receive any special
treatment (they are iterable whenever an `@@iterator` method is expected,
and they are iterated whenever a `next` method is required).
This just isn't a problem in practice. Let's solve real problems, look at
cowpaths and nearby cliffs, not try to push boilerplate onto all programmers
out of an off-target desire to make get-@iterator a "type coercion".
Huh? The suggestion in question _reduces_ boiler plate, namely the
need for every iterator to implement a braindead @@iterator method.
Yes but at the price of *every* for-of on an array, e.g., to call a
values() iterator constructor. Count the right beans. Implementors of
iterators are relatively few, especially given generators.
Failing to scale arguments about boilerplace costs by target
victim-audience size is a capital mistake.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
