Maybe ban holes, then...
On Feb 2, 2012, at 1:10 PM, Brendan Eich wrote:
Ok, you guys have holes in your head. No offense!
Holey patterns are useful, as occasionally are holey arrays. If you disagree on the latter, please acknowledge we are stuck with holey arrays for a long time, and array destructuring patterns are supplemental syntax based on a cover-grammar parse as array literals. This says holes win. If we have to argue about this, I think we'll do a disservice to bigger-impact issues that need resolution.
False alarm... You're right, they've always been in ES array literals and they are in the draft spec. for Array destructuring patterns.
If there were being proposed as a new syntactic feature (as I believe that somebody did a while ago for elisions in argument lists) that would be a different matter and I'd have some objections.
Andreas Rossberg wrote:
Are you implying that wildcards are more ad-hoc than array holes? That doesn't add up for me.
In abstract, or in other languages with wildcards, no.
In JS, yes, ad-hoc hole stomping is a waste of time and ad-hoc as far as I know ("to this", specifically toward the goal of stomping holes gratuitously). We are not adding _ magic meaning. I don't see * fitting. No one is asking for another extension here.
Onward to more pressing matters :-P.
On 2 February 2012 23:48, Brendan Eich <brendan at mozilla.org> wrote:
Andreas Rossberg wrote:
Are you implying that wildcards are more ad-hoc than array holes? That doesn't add up for me.
In abstract, or in other languages with wildcards, no.
In JS, yes, ad-hoc hole stomping is a waste of time and ad-hoc as far as I know ("to this", specifically toward the goal of stomping holes gratuitously). We are not adding _ magic meaning. I don't see * fitting. No one is asking for another extension here.
Is it clear that we don't want wildcards anyway? They seem just too damn useful and trivial, and destructuring feels rather incomplete without them.
If it's just a question of syntax, then I think . or perhaps # may be a suitable candidates.
Ok, you guys have holes in your head. No offense!
Holey patterns are useful, as occasionally are holey arrays. If you disagree on the latter, please acknowledge we are stuck with holey arrays for a long time, and array destructuring patterns are supplemental syntax based on a cover-grammar parse as array literals. This says holes win. If we have to argue about this, I think we'll do a disservice to bigger-impact issues that need resolution.
Ok, you guys have holes in your head. No offense! Holey patterns are useful, as occasionally are holey arrays. If you disagree on the latter, please acknowledge we are stuck with holey arrays for a long time, and array destructuring patterns are supplemental syntax based on a cover-grammar parse as array literals. This says holes win. If we have to argue about this, I think we'll do a disservice to bigger-impact issues that need resolution. /be > Herby Vojčík <mailto:herby at mailbox.sk> > February 2, 2012 12:21 PM > > > A bit off-topic... I don't like paretheses. Not only because I have to > put them in both ends, but also because of uncomfortable feeling of > "thing closed in parentheses". > > Maybe alternative convention to deal with expressions beginning with { > could be used as well: > > 0, {5:x} = someArray; > 0, {0:a, 2:y} = someArray; > > Herby > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > Herby Vojčík <mailto:herby at mailbox.sk> > February 2, 2012 11:49 AM > > > > > If > > {"5":x} = someArray; > > and > > {"0":a, "2":y} = someArray; > > would be possible, there is probably little need for holes. In case of > > [a,b,c,d,,f] = someArray; > > one could always use (some conventional) anon-var, like _ (from Prolog): > > [a,b,c,d,_,f] = someArray; > > Herby >