dean at deanlandolt.com
Wed Sep 28 11:21:01 PDT 2011
On Wed, Sep 28, 2011 at 12:52 AM, Brendan Eich <brendan at mozilla.com> wrote:
> On Sep 27, 2011, at 4:02 PM, Dean Landolt wrote:
> On Tue, Sep 27, 2011 at 4:57 PM, Brendan Eich <brendan at mozilla.com> wrote:
>> On Sep 27, 2011, at 1:21 PM, Dean Landolt wrote:
>> > Out of curiosity is there any reason to keep holes the holes around in
>> ObjectLiteral and ArrayLiteral?
>> No holes in ObjectLiteral.
> Apologies -- I was thinking of the trailing comma, but that's not at issue.
> Right, one (1) comma at end of either object or array literal is a
> terminator, for uniform maintenance when appending vs. inserting. Very big
> deal for those of us burned by ANSI C banning trailing single comma in C
> What bugs have you seen due to holes in literas?
> Copy/paste errors, mainly. I'd think the same rationale to justify the
> trailing comma applies against comma holes in array literals.
> 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've made this mistake more than once. This kind of bug tends to fail fast
> so it's not as easy to slip into production, but it's still a runtime error.
> Ouch. And apologies.
> What's worse, the problem is exacerbated by the fact that tools that lean
> on Array.prototype.forEach hide the hole, while those that use for(;;) treat
> it as undefined.
> That is a pain. I've heard independently that some people want forEach etc.
> to fill holes. Can you confirm?
It'd be less confusing to the novice, that's for sure. For instance the
array extras in at least one lib (dojo) still fill the holes (though I
wonder what their plans are around 2.0 when they can break back-compat?).
But there are real perf opportunities on sparse arrays when implemented
natively, so they really shouldn't go. Plus, these cases may be tricky to
catch with static analysis, so I doubt they even *could* go. But it'd be
nice to take some bullets out of the chamber of this inevitable footgun --
for starters, by making them more explicit.
> I understand that this is a problem with holes in general, and not with
> ArrayLiteral syntax in particular, but try a console.log on a holy array in,
> for instance, node and then chrome -- you'll get two VERY different-looking
> results. The way that console.log in node completely papers over array
> holes, compounded by the popularity of the comma-first style in that
> community (which makes a double-comma harder to spot),
> I find comma first just ugly on aesthetic grounds.
As do I, and I'm still no convert, but I have to say that after toying with
it for a bit this is the only substantive criticism I can make of it :)
could be a pretty nasty trap to fall into, even for a js veteran.
> Adjacent comma does scream HOLE to me, but that's just me.
Same here, but in comma-first it's not always adjacent:
var middleware = [ context,
You've got to squint a little to see that hole, right?
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 :)
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. 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.
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?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss