brendan at mozilla.com
Wed Sep 28 11:50:38 PDT 2011
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:
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss