Uninteresting parameters

[Dean Landolt]

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.



> It's true for ES6, opt-in only, we could change ArrayLiteral to remove
> holes. This would make early errors for code migrating into ES6 that uses
> holes, and for authors writing fresh ES6 programs who use holes.
>
> (Note well that [1,] is an array of length 1, no holes.)
>
>
> > Is there a real usecase (other than rare and trivial minification wins)?
> Sure, it would be a breaking syntax change but statically detectable and
> correctable. And it would wipe out a source of bugs rather than doubling
> down.
>
> 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.



> I've never seen or heard of any such bugs.



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.
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. 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), could
be a pretty nasty trap to fall into, even for a js veteran.



> The possibility of holes exists without literal syntax support, due to the
> ability to add elements to an array by assignment to non-contiguous indexes,
> delete elements, and set length.



Sure, and I'm not arguing for eliminating holes altogether...



> I don't see how to get rid of holes created via these means without making
> runtime-only, not early, errors -- and that's too big a migration tax. It's
> a source of new bugs that we could avoid by not trying to ban holes.
>
> 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, and when it's not there's
imperative syntax to fall back on. So if there's no good use for it, why
enshrine a bad practice with a declarative syntax? The migration tax would
trivial, as you alluded.



> BTW, I proposed, as part of Harmony of My Dreams, tuples:
> http://wiki.ecmascript.org/doku.php?id=strawman:tuples -- no holes,
> immutable, sane enumeration. Not in Harmony yet.
>


Yeah, those would be nice -- almost as awesome as the records you proposed
:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110927/2e511bde/attachment-0001.html>