andrea.giammarchi at gmail.com
Wed May 14 10:34:19 PDT 2014
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.
On Wed, May 14, 2014 at 10:31 AM, Andri Möll <andri at dot.ee> 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.
> 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
> 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:
>>>> 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, 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.
>>> : 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.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss