Day 2 meeting notes

[felix]

On 7/30/10 21:33, Dean Landolt wrote:
>
>
> On Sat, Jul 31, 2010 at 12:06 AM, felix <felix8a at gmail.com
> <mailto: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.

but that breaks functions like

function shallowCopy(o) {
   var p = {};
   for (var k in o) {
     if (o.hasOwnProperty(k)) {
       p[k] = o[k];
     }
   }
   return p;
}

now I have to add a test to that function for the unexpected case that o 
is an infinite iterator and the for..in loop goes forever instead of 
enumerating some finite property list.  that's just one example.  I 
expect that if iteration uses the existing for..in syntax, there will be 
many similar bits of code that will need to be modified to treat 
iterators as a special case.