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 Regards On Wed, May 14, 2014 at 10:31 AM, Andri Möll <[email protected]> wrote: > 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 < > [email protected]> 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 <[email protected]>wrote: > >> >> >> >> On Wed, May 14, 2014 at 5:37 AM, Till Schneidereit < >> [email protected]> wrote: >> >>> On Wed, May 14, 2014 at 8:48 AM, Mathias Bynens <[email protected]>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 >> [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
