Day 2 meeting notes

[Oliver Hunt]

On Jul 30, 2010, at 2:56 PM, Brendan Eich wrote:

> On Jul 30, 2010, at 2:47 PM, felix wrote:
> 
>> On 7/30/10 14:37, Brendan Eich wrote:
>>> For Harmony, we do not propose to standardize |for each|. Instead, the iteration and array comprehensions proposals for Harmony (see the wiki) propose that programmers choose keys, values, items (properties), or other iteration protocols by saying what they mean more precisely on the right-hand side of 'in':
>>> 
>>> for (k in keys(o)) ...
>>> for (v in values(o)) ...
>>> for ([k, v] in properties(o)) ... // Python's "items"
>>> 
>>> This seems better in TC39 members' views than adding ambiguous 'each' as a contextual keyword.
>> 
>> I'm wary of that because this looks to me confusing:
>>  a = keys(o);
>>  for (k in a) ...
> 
> The confusion here seems to be assuming that |a| is an Array instance. It's not. It is an iterator, so you'll get the keys (property names) found in o -- you won't get 0, 1, ... a.length-1.
> 
> To avoid this confusion you can add new syntax (|for each| or whatever, doesn't matter). I've argued in recent posts that it is better from a global and long-term point of view to reform for-in after Python, than to condemn it and grow the language with new and generally more verbose, yet similar, syntax.

It annoys me that this doesn't leave a convenient way to iterate arrays, for (... in someArray) will forever do the braindead thing.  If we look to pythonic behaviour we see that python's for..in syntax has always iterated arrays by value rather than index.  By overloading for(in) we are effectively saying that there will never be a simple way to iterate arrays by value directly, because no one can even extend the builtin array type be have a generator for iteration because doing so would be too fragile.

--Oliver