5 ms·
Unfortunately, this is not true. Although the equality operators are a favorite bikeshedding topic, the largest source of errors in JS code bases are type error
by tyri_kai_psomi 7y ago
Unfortunately, this is not true. Although the equality operators are a favorite bikeshedding topic, the largest source of errors in JS code bases are type errors. Using a "non-sane" equality check, such as those with type coercion would actually mask or alleviate these source of bugs you mention.
- aidos 7y agoI was thinking more of the case where the types match but objects and arrays with the same contents are considered different. I’ve watched every member of my team get stung by it again and again - and then have to create workarounds to get past it.
- CallocRoast 7y agoI don’t agree and this behavior shouldn’t be surprising. The alternative would be to walk the container and compare the value of each element, which could be horrible.
- BiteCode_dev 7y agoQuite the contrary, it's very beautiful and useful: >>> (1, 2) == (1, 2) True >>> (2, 1) == (1, 2) False If you need identity for perf: >>> (1, 2) is (1, 2) False If you just need the type check: >>> isinstance((1, 2), type((1, 2))) True It's very explicit, practical, and you can set the scale of practicality vs performances where you want. Plus: no implicit weird type conversion, only one equality comparison operator, and no hidden rules. I think it's sane.
- aidos 7y agoI’m not sure if you’re for or against here. Walking the container is exactly what you have to do, and it is horrible. More importantly, if it’s not your library, you don’t get any choice on how the equality check is implemented.