On Sep 10, 2014, at 12:41 PM, Boris Zbarsky wrote:
> On 9/10/14, 3:20 PM, Allen Wirfs-Brock wrote:
>> why wouldn't a self-hoster just continue with:
>> for (let next of iter} {
>> /* body */
>> }
>
> I feel like I'm missing something here.
>
> "iter" is an iterator, not an iterable. So I don't think this will do the
> right thing, unless I'm seriously missing something.
In practice (because of for-of semantics) Iterators need to be Iterables that
return themselves as the associated iterator. All built-in iterators in ES
have this characteristic
>
>> Anything either ES or WebIDL does that is hostile to that pattern is counter
>> productive as self-hosters are probably going to do that anyway, even if
>> the semantics is a slight mismatch to the spec.
>
> What I am trying to define in Web IDL is the semantics of methods that take
> an argument which is either an iterable or something else. That means they
> need to check whether the given thing is iterable, and if so iterate,
> otherwise do something else. See the thread that ended up in
> http://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/0370.html
> and the algorithm in that mail; that's what I'm specifying.
For example, Array.from does that kind of argument discrimination:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.from
>
>>> Seems to me like it's just a matter of wrapping the relevant bits (which
>>> ones, though?
>> whatever constitutes the loop "body"
>
> OK. That's fairly straightforward.
>
>> You also will need a finally clause, if the loop body contains any explicit
>> returns.
>
> It only does when the iterator claims there are no more things to be had, in
> which case do I still want to be calling the return() thing?
No, you only call 'return' when exiting the loop before the iterator has
indicated that it is 'done'..
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
