> for (var i : x) ... // must be new iteration
> for (var i : T : x) ... // iteration again, but parsed how?
> for (var i : T in x) ... // for-in with annotated var
Bummer!
I'm beginning to feel more strongly again that overloading for-in, as opposed
to introducing yet another syntactic variant of `for', is the right way to go.
<thought experiment>
Imagine we made Harmony backwards-incompatible in the following way: for-in
loops would *only* work on iterable objects, and would dynamically fail on
non-iterable objects. So if you wanted the legacy keys behavior, you would have
to explicitly call a `keys' library function.
</thought experiment>
Now say we make for-in meta-programmable in the backwards-compatible way:
non-iterable objects default to the legacy `keys' behavior, and iterable
objects use the `iterate' trap. Then old code will migrate and just work out of
the box most of the time, and lazy programmers will get programs that just work
out of the box most of the time. The only hazard is that you occasionally meant
to get keys and instead get the `iterate' behavior. How often do we really
expect this will a problem? And how often do we really expect it'll pass
through undetected? Even in the cases where you mistakenly write |for (x in
obj)| and get the iteration behavior, in many (most?) cases x will get assigned
values of some unexpected type and the program will fail pretty quickly.
I have never claimed that any solution is perfect. But I still think that the
hazards involved in overloading the for-in syntax are less costly than the
proliferation of additional syntactic forms.
Let me make yet another argument in favor of the overloaded for-in: if we had a
new form that works better than for-in, I would tell people that they should
just deprecate for-in and replace it with
for (x <<whatevermagicsigil>> keys(obj))
Why? It's more readable and explicit, and they only ever have to learn one form
in the language. By contrast, if we allowed for-in to be overloaded, I would
tell people that they should deprecate the legacy for-in and replace it with an
explicit iterator such as:
for (x in keys(obj))
And yet, there wouldn't be a proliferation of language forms, and we'd get to
use the excellent "in" syntax. Deprecating a truly sweet syntax would suck.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
