On 7/30/10 21:33, Dean Landolt wrote:
On Sat, Jul 31, 2010 at 12:06 AM, felix <[email protected]
<mailto:[email protected]>> 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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
