Uninteresting parameters

[Dean Landolt]

On Wed, Sep 28, 2011 at 2:50 PM, Brendan Eich <brendan at mozilla.com> wrote:

> 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.
>


Touché.


> 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.
>

Unless this syntax were stricken from the language, of course :)

[snip]

>
>> 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 :)
>
>
> I already noted those, but did you look at the ones that looked
> intentional? We don't get to kick stuff out lightly.
>


Examples not in a test, comment, or string literal are pretty sparse. Here's
the first use I came across:

http://codesearch.google.com/#sgZapbbRTzk/trunk/sites/ikariam.org/kronos_utils.user.js&q=%22,%20,%22%20lang:%5Ejavascript$&ct=rc&cd=17&sq=

This could be rewritten to zero-pad the `cols` and `title` arrays and use
delete explicitly, but yeah, I get that this isn't pretty. A length-setting
operation that added the holes to head would be useful. Or even better, a
means to slide any array slice around, leaving holes in its wake. But as you
say, no one really talks much about holes, so this is all overkill...

Which is why I was suggesting holes be explicit -- perhaps a new type. In
order to avoid a runtime compatibility break it would have to be a subtype
of void 0. After thinking it through a bit this would be tough to do without
introducing yet another type system. So yeah, not worth it for this rare
edge case...

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.
>


Sure, but it introspecting objects can't present this problem.


> 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.
>


I was specifically objecting to the ArrayLiteral hole syntax, as well as
suggesting the idea of filling these holes with a new type (something akin
to the bottom type). With or without the latter the former still smells.
Admittedly, without the latter the migration is uglier, but it could
*still*be done statically. It seems like a good tradeoff to me -- the
only
constituencies that really lose are the code golfers, but they've got plenty
of clubs in their bags.

One final point: if its worth having holes at all (and IMHO it is) we *
definitely *need more API surface to work with them from userland. This
means, at the very least, we need a way of finding where holes start that's
better than O(N).


[snipped the rest]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110928/7a05dd4d/attachment.html>