3 ms·

Right, this seems like exactly why we shouldn't be allowed to redefine it. As a reader of your code that redefines ==, I think == means we are talking identity

by wdewind 11y ago

Right, this seems like exactly why we shouldn't be allowed to redefine it. As a reader of your code that redefines ==, I think == means we are talking identity until I find your function that redefines ==. It has made it so I need to understand more things in order to be able to reason about your code. That seems like a negative to me.

byroot 11y ago
That's because you are among the people who don't like abstractions. I disagree with that opinion, but that's fine, Ruby is just definitely not for you. Don't try to change or complain about Ruby, you are likely more happy with languages like go.
- wdewind 11y ago
  > That's because you are among the people who don't like abstractions. That's not the issue at all. Abstractions are great. Redefining operators is not abstraction, it's practically obfuscation.
  - byroot 11y ago
    It is. By redefining the equality method (operators are just regular methods really), you abstract away how this kind of object need to be compared with it's peers. The fact that it's an operator or a method doesn't change a thing. For example in Java many classes redefine the `equals` method. It's default behavior is just like Ruby, comparing identity. It's not an operator but the effect is exactly the same. And IMO it's worse because now you have a leaky abstraction with types you need to compare with `==` and others with `.equals`. It's just you who have this expectation of operators being not redefinable. When I read Ruby code, for me `==`, or `+` are just regular methods like any others with just a bit of syntactic sugar. It also allows for greater polymorphism. Like the Money object from before. If I couldn't redefine `+`, then `[Money.new(20), Money.new(22)].sum` wouldn't work.
icebraining 11y ago
But even in core Ruby, == is not always identity; hashes, arrays, ranges, all of them are compared by value and not by identity. The assumption that == is comparing identity is broken, not the code that implements it differently.
- wdewind 11y ago
  For "primitives" yes, for objects no. What would be primitives in Ruby extend Object, because everything in ruby does, but (sigh) they redefine == so they act more like primitives in other languages. At least there is a clear cut rule, but it's pretty much turtles all the way down.
  - icebraining 11y ago
    But there are no primitives in Ruby, that's the point. Everything is an object, and some objects extend ==, others don't, even in the core language.
chc 11y ago
If somebody wants object identity rather than semantic equality, they should be using `equal?`. The fact that different types have different equality semantics if just kind of inherent in the idea of a type.

by wdewind 11y ago

byroot 11y ago

That's because you are among the people who don't like abstractions. I disagree with that opinion, but that's fine, Ruby is just definitely not for you. Don't try to change or complain about Ruby, you are likely more happy with languages like go.

wdewind 11y ago
> That's because you are among the people who don't like abstractions. That's not the issue at all. Abstractions are great. Redefining operators is not abstraction, it's practically obfuscation.
- byroot 11y ago
  It is. By redefining the equality method (operators are just regular methods really), you abstract away how this kind of object need to be compared with it's peers. The fact that it's an operator or a method doesn't change a thing. For example in Java many classes redefine the `equals` method. It's default behavior is just like Ruby, comparing identity. It's not an operator but the effect is exactly the same. And IMO it's worse because now you have a leaky abstraction with types you need to compare with `==` and others with `.equals`. It's just you who have this expectation of operators being not redefinable. When I read Ruby code, for me `==`, or `+` are just regular methods like any others with just a bit of syntactic sugar. It also allows for greater polymorphism. Like the Money object from before. If I couldn't redefine `+`, then `[Money.new(20), Money.new(22)].sum` wouldn't work.

icebraining 11y ago

But even in core Ruby, == is not always identity; hashes, arrays, ranges, all of them are compared by value and not by identity. The assumption that == is comparing identity is broken, not the code that implements it differently.

wdewind 11y ago
For "primitives" yes, for objects no. What would be primitives in Ruby extend Object, because everything in ruby does, but (sigh) they redefine == so they act more like primitives in other languages. At least there is a clear cut rule, but it's pretty much turtles all the way down.
- icebraining 11y ago
  But there are no primitives in Ruby, that's the point. Everything is an object, and some objects extend ==, others don't, even in the core language.

chc 11y ago

If somebody wants object identity rather than semantic equality, they should be using `equal?`. The fact that different types have different equality semantics if just kind of inherent in the idea of a type.