Discuss
  • Array.prototype.last

Array.prototype.last

# David Bruant (11 years ago)

Asked by Angus Croll. Interestingly, people who answered giving code didn't agree on a method or getter. Hence the need for a standard :-) Array.prototype.first could work too.

# Alexandre Morgaut (11 years ago)

Using a method would be jQuery like:

but jQuery didn't had much choice has JS getter / setter are not supported by older browsers

The DOM API expose first / last child via properties since DOM level 1

As does Element Traversal

Properties would be more logic to me but I'm not sure if they are really necessary It provides a little more semantic friendly access and is a little more friendly for autocompletion

# David Bruant (11 years ago)

Le 28/07/2013 16:03, Alexandre Morgaut a écrit :

but jQuery didn't had much choice has JS getter / setter are not supported by older browsers

If it's added, let's build for the future and make a getter. People who want IE8- support can always use [.length - 1]

# Alexandre Morgaut (11 years ago)

But note that last and first usually return iterators providing next & previous properties or methods As Array items can be of any type it would mean adding a behavior to them (a polyfil could use apply() or call() to add it) next / previous should then also alter the returned item

# Jorge Chamorro (11 years ago)

I've seen that before, somewhere, but it was .peek() not .last:

[1,2].peek()
2
# Axel Rauschmayer (11 years ago)

Wondering: If most data structures in ES6 use the methods get() and set(), couldn’t we add those to arrays and then simply allow negative indices?

Then we’d be able to do the following:

> let arr = [ 'a', 'b', 'c' ];
> arr.get(-1)
'c'

That’d be kind of like a negative version of Allen’s “Object Model Reformation” proposal: strawman:object_model_reformation

# Tab Atkins Jr. (11 years ago)

On Sun, Jul 28, 2013 at 7:38 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

Wondering: If most data structures in ES6 use the methods get() and set(), couldn’t we add those to arrays and then simply allow negative indices?

I am totally down with this. It also means we can turn Arrays into Map-likes by filling out the rest of the methods.

# Andrea Giammarchi (11 years ago)

reasons I've suggested a getter is the affinity with DOM indeed while for the "Object redefinition" part looks basically what I've simulated here: WebReflection/another-js#anotherjs-api

able to use emulated reflection too. Didn't know about Allen proposal, cool stuff!

# Dmitry Soshnikov (11 years ago)

Exactly at the moment I'm writing too many of

entries[entries.length - 1]

where entries is an array (with of course moving to a helper function/prototype method).

Will it make sense to add it now to ES6?

For consistency with Object.keys(), it could be exactly a function, not a getter:

entries.last()

For correlation with entries.length, it could be the getter, yes

entries.last

Both work well, just need to peek more practical.

The pop() is similar, but removes the element.

(the issue was discussed before, not sure whether it was decided not to include it, or was it's just forgotten - don't see it in the draft, but seems the useful thing: if not for ES6, probably for ES7)

(Alternative: entries.peek())

Dmitry

# Kris Kowal (11 years ago)

I am in favor of last() and first() particularly because other collections like queues and sorted sets can implement it and grow the common interface of ordered collections. I also favor the last() and first() bike-shed colors. I wrote a query and binding language that already uses these forms.

documentup.com/montagejs/frb/#tutorial/last

Kris Kowal

# Rick Waldron (11 years ago)

I agree, this is a reasonable addition, however:

On Tue, May 13, 2014 at 2:54 PM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com> wrote:

Will it make sense to add it now to ES6?

No, ES6 is closed for all new features—but you should absolutely write up a proposal (gist is fine, here are examples: gist.github.com/rwaldron/11186883, gist.github.com/WebReflection/9353781) and submit a PR to: tc39/ecma262

# Dmitry Soshnikov (11 years ago)

Thanks for the info, Rick

Yeah, I know it's closed, that's why mentioned that then probably for ES7. Just thought, the addition is so trivial, that could possibly and easily be included to ES6.

Although, taking into account some stylistics questions (getter vs method, and the name), probably it's not that trivial, and would require time to discuss. So, yeah, a detailed proposal seems is better way to go.

Dmitry

# Rick Waldron (11 years ago)

The get accessor approach is nice, I prefer it to the method version.

# Kevin Smith (11 years ago)

I agree this would be a great little addition for ES7.

# Mathias Bynens (11 years ago)

Previous discussion on this topic: esdiscuss.org/topic/array-prototype-last

We should look at how existing utility libraries handle this behavior and base any proposals on that IMHO. Underscore and Lo-Dash have _.first and _.last, which both take an optional callback parameter, in which case all the first/last n elements for which callback returns a truthy value are returned. This seems like a sensible thing to add to the proposal.

# Till Schneidereit (11 years ago)

While I think having .last would be nice, I don't think it's worth the considerable backwards-compatibility issues. We had to temporarily back out Array#values from SpiderMonkey until we implement @@unscopable semantics1, because we ran into serious real-world breakage. I'm pretty sure that "last" would break a lot more code, as it's even easier to think up scenarios where that'd be used as a property name on an array used in application logic.

At the very least, I think having Array#last be a getter is entirely untenable: a method would at least just be overwritten in most cases, whereas a read-only accessor would just (silently, in non-strict code) fail. A read-write accessor would probably be even worse: it'd silently (in all code) do something entirely different than it did before.

I do, however, like Axel's proposal of adding .get() and .set() to Array.prototype, and think that that'd be way less of a compatibility issue.

# Rick Waldron (11 years ago)

I forgot about this, thanks for posting. I like get() much better as it can be a "first" or a "last" (or any in between) with less surface impact.

# Andrea Giammarchi (11 years ago)

I like we keep adding get and set here and there but I hope we are not forgetting to fix descriptors inheritance problem where any get or set can compromise Object.defineProperty operations (just a gently reminder that get and set if inherited can cause many troubles in ES5 like operations)

Best

# Andri Möll (11 years ago)

How are they related? Wouldn't that affect Object.defineProperty only if someone passes it an object inheriting from array, for which I can't think any valid reason for.

Andri

# Andrea Giammarchi (11 years ago)

Same "any valid reason" inheritance should be considered for descriptors ... I didn't want to go off topic too much, just remind that these methods name have a very important meaning in some case.

Best