Uninteresting parameters

[Brendan Eich]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110928/84274257/attachment.html>