Uninteresting parameters

[Dean Landolt]

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
> enum!
>
>
> 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,
                 , csrf
                 , xsite
                 , head
                 , considtional
                 , error
                 ]

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:
>
>
> http://codesearch.google.com/#search/&q=%22,%20,%22%20lang:^javascript$&type=cs<http://codesearch.google.com/#search/&q=%22,%20,%22%20lang:%5Ejavascript$&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 :)

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...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110928/54ffc245/attachment.html>