On Sep 28, 2011, at 11:21 AM, Dean Landolt wrote: > Hmm, I think I see what you mean, but the hole case is different enough and > anyway it has been in the language for 12 years. > > > True enough, but wouldn't you say it's still commonly misunderstood?
I don't hear enough about hole literal syntax to say that. > Same here, but in comma-first it's not always adjacent: > > var middleware = [ context, > , csrf > , xsite > , head > , considtional > , error > ] > > You've got to squint a little to see that hole, right? That is horrible, and a reason to reject comma first. It mixes badly with comma last, and mixing is inevitable -- and I agree, hard to see due to separation onto two or more lines. > >> So, if we still have holes, is it really worth getting rid of ArrayLiteral >> support for them? I think not. >> >> >> But are they of any real use for ArrayLiterals? IMHO a hole in a small array >> (i.e. an ArrayLiteral) is almost always a mistake, > > Or a testcase for the otherwise unwanted feature: > > http://codesearch.google.com/#search/&q=%22,%20,%22%20lang:^javascript$&type=cs > > Some of those look intentional, and non-testy, though. > > > But what does it say that the so many are just explicitly testing this edge > case? And an entry from wtfjs, right there on the first page :) I already noted those, but did you look at the ones that looked intentional? We don't get to kick stuff out lightly. > > Another wart that springs to mind is the fact that a hole === void 0 but is, > in fact, not void 0. I guess technically this is correct -- reifying the > index gets you void 0 -- but it's still odd. This is true with missing properties of any kind. > If there were a way to indexOf for the first hole, for instance, this would > at least allow them to be exploited in userland code for more efficiently > spare array looping constructs -- that alone would be a win. Holes are not going away, we agree. Seems to me you're objecting to consequences of holes we can't eliminate without runtime-only compatibility breaks. > But really, my real beef is with the variance in behaviors for the array > extras. IMHO the best bet would be for these APIs to grow an opt-in option to > skip holes, but that ship probably sailed: an opt-in would be breaking and > not statically analyzable; an opt-out would defeat the purpose -- if you're > aware of holes you'd almost always want to skip over them, right? Right, and who wants more knobs on existing APIs. Probably we should write generic functions in modules, a la itertools2. Let the old stuff on Array.prototype lie still. > So one reasonable alternative would be to promote holes into a real language > construct we can both visualize and exploit from userland explicitly, along > with fixing as much of the API surface as is practical that creates them > implicitly -- starting with holes in array literals. I agree holes need better handling in future arraylike "extras". Design effort there can start now, using today's JS. I'd welcome it. Perhaps underscore does well already? /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
