<br><br><div class="gmail_quote">On Wed, Sep 28, 2011 at 12:52 AM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div class="im"><div>On Sep 27, 2011, at 4:02 PM, Dean Landolt wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Tue, Sep 27, 2011 at 4:57 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<div>On Sep 27, 2011, at 1:21 PM, Dean Landolt wrote:<br>
<br>
> Out of curiosity is there any reason to keep holes the holes around in ObjectLiteral and ArrayLiteral?<br>
<br>
</div>No holes in ObjectLiteral.<br></blockquote><div><br></div><div><br></div><div>Apologies -- I was thinking of the trailing comma, but that's not at issue.</div></div></blockquote><div><br></div></div>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 enum!</div>
<div><br></div><div><div class="im"><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
What bugs have you seen due to holes in literas? </blockquote><div><br></div><div><br></div><div>Copy/paste errors, mainly. I'd think the same rationale to justify the trailing comma applies against comma holes in array literals.</div>
</div></blockquote><div><br></div></div>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.</div></div></blockquote><div> </div><div><br></div><div>
True enough, but wouldn't you say it's still commonly misunderstood?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">
<div><div class="im"><blockquote type="cite"><div class="gmail_quote">
<div>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.</div></div></blockquote><div><br></div></div>Ouch. And apologies.</div>
<div><br></div><div><br></div><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><div> 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.</div>
</div></blockquote><div><br></div></div>That is a pain. I've heard independently that some people want forEach etc. to fill holes. Can you confirm?</div></div></blockquote><div> </div><div><br></div><div>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?).</div>
<div><br></div><div>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 <i>could</i> 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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><div>
 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),</div>
</div></blockquote><div><br></div></div>I find comma first just ugly on aesthetic grounds.</div></div></blockquote><div> </div><div><br></div><div>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 :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div class="gmail_quote">
<div> could be a pretty nasty trap to fall into, even for a js veteran.</div></div></blockquote><div><br></div></div>Adjacent comma does scream HOLE to me, but that's just me.</div></div></blockquote><div> </div><div>
 </div><div>Same here, but in comma-first it's not always adjacent:</div><div><br></div><div><div><font class="Apple-style-span" face="'courier new', monospace">var middleware = [ context,</font></div><div><font class="Apple-style-span" face="'courier new', monospace">                 , csrf</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">                 , xsite</font></div><div><font class="Apple-style-span" face="'courier new', monospace">                 , head</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">                 , considtional</font></div><div><font class="Apple-style-span" face="'courier new', monospace">                 , error</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">                 ]</font></div></div><div><br></div><div>You've got to squint a little to see that hole, right?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
So, if we still have holes, is it really worth getting rid of ArrayLiteral support for them? I think not.<br></blockquote><div> </div><div><br></div><div>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,</div>
</div></blockquote><div><br></div></div>Or a testcase for the otherwise unwanted feature:</div><div><br></div><div><a href="http://codesearch.google.com/#search/&q=%22,%20,%22%20lang:%5Ejavascript$&type=cs" target="_blank">http://codesearch.google.com/#search/&q=%22,%20,%22%20lang:^javascript$&type=cs</a></div>
<div><br></div><div>Some of those look intentional, and non-testy, though.</div></div></blockquote><div> </div><div> </div><div>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 :)</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>So one reasonable alternative would be to promote holes into a real language construct we can both <i>visualize </i>and <i>exploit</i> 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.</div>
<div><br></div><div><br></div></div>