Day 2 meeting notes

[Dean Landolt]

On Sat, Jul 31, 2010 at 12:06 AM, felix <felix8a at gmail.com> wrote:

> On 7/30/10 14:56, 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.
>>
>
> I should have used a letter other than 'a'.  my expectation from current
> javascript is that 'a' is an object, and that 'for (k in a)' will iterate
> over the object's properties.
>

That's a fair assumption given the current state of the language, but
assumptions will change with time. Perhaps if you named "a" something like
aIter (wow, this example makes for a good argument for the snakecase
a_iter), you're expectations would be re-framed.

I think the common usage pattern will be using these iteration protocols at
the point of consumption, as with the examples Brendan's given -- and in
this case they're effectively anonymous and naming is a non-issue. You could
expect functions like keys(a), values(a) -- or whatever protocol functions
your library-of-choice provides -- to do *just *what they say. In this light
I don't believe an iterator's for..in behavior is surprising at all, even w/
collective our es3 baggage.


>
> it seems odd to me that if 'a' is an iterator, it will iterate over the
> iterator's value stream instead of the iterator's properties, unless you
> define the two to be identical, which would be strange.  eg, if you have an
> input stream iterator f, would f.hasOwnProperty('bacon') work or not?
>

But they're different objects entirely. If a's a "values" iterator it's not
iterating over it's *own* value stream -- it's iterating over some other
object's value stream. Thus, f.hasOwnProperty('bacon') shouldn't work
(unless you've bacon'd your iterator, of course, or done some magic with
proxy objects). So if f is iterating over an object's value stream then you
have a reference to the underlying object if you want to do anything like
hasOwnProperty.

>
> yes, I'd like generalized iterators like python, so this is not really an
> argument.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100731/04081044/attachment-0001.html>