On Nov 22, 2010, at 5:39 PM, Allen Wirfs-Brock wrote:
> AWB: Thanks, I like that. Trying to articulate some principles was the main
> point. I felt the thread was feeling like it getting hung up on unstated
> and/or unshared prinicples.
I agree, and I try to make mine clear (let me know where I fail). It's
important not only for reaching agreement (backing up and trying a different
deductive path forward) but also in rejecting bogus premises, or reprioritizing.
> AWB: I worry that it is hard for people to learn when the same name is
> applied to different concepts. We already have two forms of the "for"
> statement that people have to learn.
The C-based for(;;) loop is not really relevant in my experience. JS hackers
use it (more below on why they might rather not), but they always distinguish
it from "for-in".
Some good fraction of JS hackers know Python, where for-in has enumeration like
behavior on dictionaries (just like JS objects), but value iteration on lists.
The most frequent (in my hearing) unsatisfied expectation of users of for-in is
not that it is a second form after the C-based for(;;) -- there's no mention of
for(;;). Rather, it is that for (v in [1,2,3]) fails to iterate 1,2,3, instead
enumerating "0","1","2".
We can't satisfy this Pythonic expectation directly, but with meta-programmable
for-in, users and library authors can help themselves, using keys, values, and
other iterator factory functions.
> Further complicating it feels like it would be a pedagogical nightmare.
I think this is exaggerated -- there's really no relation to for(;;), and the
first-year students move up and on.
The nightmare of unprogrammable for-in, if I may use that word, is both the
non-interoperable mess of for-in today in ES3-ES5-level browsers, plus the
enumerate trap of tomorrow -- never mind an iterate trap. But most programmers
do not need to know about proxies.
So weigh the nightmares by how many students reach "JS grad school", where they
learn about proxies at all.
And give some weight to middling students of the future libraries, who will be
able to for-in over array and other array-like objects' values. The C-style for
(var i=0; i < a.length; i++) { var v = a[i]; ... } alternative-nightmare would
be vanquished by the dawn of for (var v in values(a)) { ... }.
This is all kind of fluffy, on both sides of our argument. Are we really
concerned about cognitive load of for (;;) vs. for-in? That ship sailed long
ago and I argue it's as likely that meta-programmable for-in heals the rift, as
it is that iterate on top of enumerate makes a new rift.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
