3 ms·

$ irb2.4.1 :001 > ({k: 1} === {k: 1}) => true I don't get it. Why would you not want this? And when you're used to it working, how could missing so common and

• darepublic 8y ago
  I guess it's not maddening to me because I was used to this from C. Two pointers which resolve to the same value and type will still not be equal in an equality expression if they reference different addresses. But to me it's good that {k: 1} !== {k: 1}, because if this evaluated to true I would have no way of determining an object's true identity, which is often more relevant than the value it contains.
  • peteforde 8y ago
    You make a (several) good points. I primarily work in Ruby and it's true that comparing a potentially complex object like a hash based on whether it serializes identically essentially means that you're comparing by value instead of reference. Depending on what you're doing, that's either really convenient or a nightmare. Ruby seems well adjusted to tasks where accessing a hash as a value is a feature and not a bug. And for those times where you're interested in comparing instances of a hash, every instance of an object has an object_id getter: a = {k: 1} b = {k: 1} a == b # true a.object_id == b.object_id # false Of course, this is a lot of typing, so Matz also gave us: a.equal? b # false Ultimately, this is what I love about the diversity of a pluralist language ecosystem. The polyglots will always win.