Array.prototype.last()

Andri Möll andri at dot.ee
Wed May 14 10:31:28 PDT 2014


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

On May 14, 2014, at 8:10 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

> 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 Regards
> 
> 
> On Wed, May 14, 2014 at 8:00 AM, Rick Waldron <waldron.rick at gmail.com> wrote:
> 
> 
> 
> On Wed, May 14, 2014 at 5:37 AM, Till Schneidereit <till at tillschneidereit.net> wrote:
> On Wed, May 14, 2014 at 8:48 AM, Mathias Bynens <mathiasb at opera.com> wrote:
> Previous discussion on this topic: http://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`](http://lodash.com/docs#first) and [`_.last`](http://lodash.com/docs#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 semantics[1], 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[2] of adding .get() and .set() to Array.prototype, and think that that'd be way less of a compatibility issue.
> 
> 
> [1]: https://mail.mozilla.org/pipermail/es-discuss/2013-July/thread.html#32185
> [2]: http://esdiscuss.org/topic/array-prototype-last#content-5
> 
> 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. 
> 
> Rick
> 
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140514/038e9e53/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4790 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140514/038e9e53/attachment.p7s>


More information about the es-discuss mailing list