Use Object.is when testing for equality where the === operator was previously used #120
Conversation
|
It looks good. I wunder what the performance impact will be. I also think we should use the native Object.is if it is available. I don't think it is a problem that we have to mention that we use Object.is sematic in the doc. |
From running the test suite multiple times before and after the change I couldn't measure any difference.
That is how I implemented it, see https://github.com/sunesimonsen/unexpected/blob/objectIs/lib/utils.js#L11 The drop in coverage is due to the polyfill only getting exercised by |
|
Sorry I overlooked that fact that you have it chose the native version if it was available. |
|
LGTM 👍 |
…eviously used. This affects the 'to be' and 'to equal' assertions and means that NaN is considered equal to itself, whereas -0 and 0 are considered different. Closes #116.
Use Object.is when testing for equality where the === operator was previously used
This affects the 'to be' and 'to equal' assertions and means that NaN is considered equal to itself, whereas -0 and 0 are considered different.
Consider this a spike at this point. I realize that the additional text required in the docs to explain the departure from
===is a drawback in itself.Closes #116.