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
ToIterator(obj)
return the result of Invoke(obj,@@iterator,())
or
ToIterator(obj)
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.
Allen
On Jun 12, 2013, at 3:55 AM, Andreas Rossberg wrote:
> On 11 June 2013 21:19, Brendan Eich <[email protected]> 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.
>
> WDYT?
>
> /Andreas
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
