Array.prototype.last
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
- www.w3.org/TR/2007/WD-ElementTraversal-20070727/#elementTraversal-firstElementChild
- www.w3.org/TR/2007/WD-ElementTraversal-20070727/#elementTraversal-lastElementChild
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
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]
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
I've seen that before, somewhere, but it was .peek() not .last:
[1,2].peek()
2
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
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.
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!
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
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
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
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
The get accessor approach is nice, I prefer it to the method version.
I agree this would be a great little addition for ES7.
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.
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.
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.
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
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
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
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.