Re: Why can’t for-of be applied to iterators?
allen at wirfs-brock.com
Wed Jun 12 09:37:48 PDT 2013
Personally, I don't really think about what is going on here as a type coercion but I have no problem if you what to explain it as applying ToIterator. It may even be useful to use this in the spec.
The Iterator and Iterable interfaces that I currently have defined in the draft are not really used in a normative manner anywhere but I think they are a convenient short hand. Iterable is just shorthand for "has a @@iterator method". Iterator just means "has a "next" method that returns a iteration result object". Some objects are both an Iterable and an Iterator. I think of "throw" as part of the generator interface and yield as expecting either an iterable, an iterator or a generator as an argument.
To me the only substantive question we have on the table is whether "ToIterator" is defined as
return the result of Invoke(obj,@@iterator,())
if obj has @@iterator return the result of Invoke(obj,@@iterator,())
else return obj
The spec. draft currently uses the equivalent of the first in for-of. I think changing it to the second would be fine.
On Jun 12, 2013, at 3:55 AM, Andreas Rossberg wrote:
> On 11 June 2013 21:19, Brendan Eich <brendan at mozilla.com> wrote:
>> Andreas Rossberg wrote:
>>> That makes a terrible API, though. I think Axel has a valid point that
>>> the distinction between iterators and iterables is fuzzy enough to be
>>> more confusing and error-prone than useful.
>> Have you actually used Python or JS1.7 much, though?
>> Have to ask, since throwing "confusing" and "error-prone" charges demands
>> evidence or at least anecdotes.
> It is confusing me, for one -- I don't really understand the
> difference anymore, nor the intended use cases. Granted, I might be
> the only one confused. I'm not ready to believe that, though. ;)
> You see, initially the iterator proposals tried to suggest a simple
> and understandable model: iterators were objects with a 'next' method,
> iterables were objects with an @@iterator method that produces an
> iterator. But neither is true anymore:
> - Iterators are iterables, they are supposed to have a 'next',
> optionally a 'throw', and an @@iterator method that returns itself.
> That is, the iterator interface has become considerably more
> complicated and is mutually intertwined with iterables.
> - Iterables are iterators most of the time, except when they aren't.
> Their @@iterator method may produce a new iterator or, in most cases,
> not. That is, there is no useful contract of what an iterable is, and
> it is useless as a concept to implement abstractions against.
> Nevertheless, people will probably try, and then build something that
> does not reliably work for all iterables. Thus error-prone.
> Where things stand now, the only reason we have @@iterator at all is
> as a hook to provide implicit user-defined conversions from objects to
> iterators, invoked by the for-of loop (and by extension, yield*).
> We could simplify spec _and_ programmers' life by explicitly
> recognizing it as such. That is, for-of invokes a ToIterator
> conversion meta function, which is the identity for any 'nextable',
> and tries to invoke @@iterator for others. Thereby drop the misleading
> notion of iterable, and drop the weird requirement for iterators to be
> iterables themselves.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss