jashkenas / underscore / 2513 / 1

95%

master: 95%

Pull #2601

travis-ci

<a href="https://github.com/jashkenas/underscore/commit/<a class=hub.com/jashkenas/underscore/commit/befef0af5717e4c3eb5bf93533403da43bcc54cd">befef0af5<a href="https://github.com/jashkenas/underscore/commit/befef0af5717e4c3eb5bf93533403da43bcc54cd">&quot;&gt;Remove test for edge case: _.reject(list, []);

I believe this test was added by accident by @megawac in #1582
(specifically </a><a class="double-link" href="https://github.com/jashkenas/underscore/commit/<a class="double-link" href="https://github.com/jashkenas/underscore/commit/ca404d40f1705ffc84c5cd8a8a95a04373df2c76">ca404d40f</a>">ca404d40f</a><a href="https://github.com/jashkenas/underscore/commit/befef0af5717e4c3eb5bf93533403da43bcc54cd">)

Given our current documentation, the behavior of this edge case is not
defined.

This test currently passes because arrays are technically objects and
thus `_.iteratee` treats `[]` as a `_.matches` matchers. `_.matches`
casts `[]` to `{}` via `_.extendOwn({}, []);` and returns a function
witch always returns `true`.

The fact that this test exists in `_.reject`&#39;s test and not in
`_.iteratee`&#39;s leads me to believe that this is not actually intended
behavior, but merely an implementation detail which has been
accidentally enforced in our tests.

I&#39;m currently reworking my pull request #2494 (deep property access) and
in a future where arrays are used for deep property access, `[]` will
return a function that always returns `undefined`, which seems like
a more reasonable behavior.

I thought it would be good to have this conversation separate from the
deep property matching pull request, but removing this test is
a prerequisite to implementing deep property access.

771 of 797 relevant lines covered (96.74%)

17238.1 hits per line