Nitpicking here, but the `nth` method is traditionally named `at`, if it were going to be formally proposed
> On Jan 25, 2016, at 3:00 PM, Andrea Giammarchi <[email protected]> > wrote: > > `Array.prototype.nth(n=0)` looks great indeed, +1 here > > About the Symbol ... ugly as hell also we need to write even more and it > doesn't scale as utility compared to .nth > > ```js > a[Symbol.last] > a[a.length-1] > ``` > > I mean, seriously ... don't even consider that or someone might ask to > implement `Symbol.first` with second, third and all others too ... how about > `Symbol.odd` /sarcasm > > Best Regards > > > >> On Sat, Jan 23, 2016 at 8:56 PM, Michał Wadas <[email protected]> wrote: >> I can't consider `.last(1)` method to be readable... >> But I think `.nth(n)` method with support for negative index would be really >> useful. >> >> 2016-01-23 17:32 GMT+01:00 kdex <[email protected]>: >>> Not every feature addition is due to performance or paradigms. Just have a >>> look at ES2015: I'm sure that this has neither been the motivation for >>> `String.prototype.startsWith`nor for `String.prototype.includes`. Even >>> `String.prototype.repeat` appears so simple that a loop paired with a >>> concatenation could have become a popular alternative. >>> >>> Of course you could solve most of these string problems with earlier >>> versions >>> of the language, too, often explicitly thinking with incides. But on the >>> downside, your code suddenly becomes a potentially unintuitive, index-ridden >>> mess, introducing off-by-one and out-of-bound errors (it even happened to >>> someone on this thread, too, if you review Thomas' code from above). This >>> isn't really all too much about saving keystrokes, but mainly about writing >>> clean, readable and maintainable code. >>> >>> There's array::back in C++, negative indices in Python as well as Bash or >>> end >>> in PHP, so I don't see any reason why we should complicate things for people >>> coming from these languages. Nor to I see why we should torture ourselves >>> thinking about how the underlying data structure stores its elements >>> internally when all I care about is reading the last element. >>> >>> Just ask yourself: Do you think it's substantially more readable to write >>> >>> ```js >>> [1, 2, 3].slice(-2)[1]; >>> ``` >>> over >>> ``` >>> [1, 2, 3].last(1); >>> ``` >>> ? >>> >>> If it comes to write access, I agree that`Symbol.last` could be another >>> handy >>> addition (it doesn't have to be an "either/or" discussion, really): >>> >>> [1, 2, 3][Symbol.last]; // 3 >>> [1, 2, 3][Symbol.last] = 4; // 4 >>> [1, 2, 3].last(1); // 2 >>> >>> On Samstag, 23. Januar 2016 18:01:24 CET Bob Myers wrote: >>> > On Sat, Jan 23, 2016 at 12:54 PM, kdex <[email protected]> wrote: >>> > > [1, 2, 3].last(); // 3 >>> > >>> > I'm wondering what the ultimate motivation for suggestions like this is. >>> > Is >>> > it to save key strokes? Allow more semantic coding? Support new paradigms? >>> > Performance? 'm sure someone has already come up with a good >>> > categorization >>> > like this, would someone mind providing a link? Could one of these be >>> > considered the "theme" for the next version? >>> > >>> > I have to admit to be being quite negative about proposals of the form >>> > "Hey, this other language does X, can we do that too?", or "It would be so >>> > cool if we could do Y", especially when these are mostly about syntax. Is >>> > a >>> > missing `last` really one of our painpoints? >>> > >>> > Bob >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
