4 ms·

Can you give me an example of where redefining equality makes sense?

by wdewind 11y ago

JoeAltmaier 11y ago
Without explicit comments/documentation it is hard to imagine a good example. Its a longstanding issue. Even Lisp has 'equals' and 'equals?' which is an abomination. One looks for identity of object; the other for identity of value (if I understand it right). These kind of things are bug factories.
- icebraining 11y ago
  I think Python make the difference clear, with == vs "is".
  - msbarnett 11y ago
    Ruby provides object_id for the same purpose. Comparing those for equality provides the "is_" semantics.
- deckard1 11y ago
  Kent Pitman has always been a good read, for the problems of equality in dynamic languages. The typical Ruby or JS programmer stumbles through the day just "getting by", where it comes to comparing objects. http://www.nhplace.com/kent/PS/EQUAL.html http://www.nhplace.com/kent/PS/EQUAL.html
- lispm 11y ago
  Lisp does not have 'equals' and 'equals?'. Lisp has 'eq', which is for object identity. Lisp has 'equal' which checks for structural equality.
  - JoeAltmaier 11y ago
    and 'equals?'
byroot 11y ago
Anytime you have some value type. Say a `Money` class for instance. The default `==` from Object compare identity, so unless you define it `Money.new(20, 'USD') != Money.new(20, 'USD')`.
- 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.
regularfry 11y ago
Any value type.
adrianmacneil 11y ago
Another (even more simple than Money) example are many of the standard library classes. For example BigDecimal. With operator overloading, I can easily compare a BigDecimal object to an integer or float, the same way I can already compare them to each other: BigDecimal.new("10.0") == 10.0 10 == 10.0 Without operator overloading, this would become needlessly messy (and require explicit handling of nils): d = BigDecimal.new("10.0") !d.nil? && d.value_equal_to(10.0) Ruby has always been about readability of the code, and avoiding unnecessary repetition, and I think operator overloading (when used correctly) is a great example of this.
waxjar 11y ago
My personal favorite: a safe, constant time equality method for cryptographic stuff.

Can you give me an example of where redefining equality makes sense?

by wdewind 11y ago

Can you give me an example of where redefining equality makes sense?

Without explicit comments/documentation it is hard to imagine a good example. Its a longstanding issue. Even Lisp has 'equals' and 'equals?' which is an abomination. One looks for identity of object; the other for identity of value (if I understand it right). These kind of things are bug factories.

icebraining 11y ago
I think Python make the difference clear, with == vs "is".
- msbarnett 11y ago
  Ruby provides object_id for the same purpose. Comparing those for equality provides the "is_" semantics.
deckard1 11y ago
Kent Pitman has always been a good read, for the problems of equality in dynamic languages. The typical Ruby or JS programmer stumbles through the day just "getting by", where it comes to comparing objects. http://www.nhplace.com/kent/PS/EQUAL.html http://www.nhplace.com/kent/PS/EQUAL.html
lispm 11y ago
Lisp does not have 'equals' and 'equals?'. Lisp has 'eq', which is for object identity. Lisp has 'equal' which checks for structural equality.
- JoeAltmaier 11y ago
  and 'equals?'

byroot 11y ago

Anytime you have some value type. Say a `Money` class for instance. The default `==` from Object compare identity, so unless you define it `Money.new(20, 'USD') != Money.new(20, 'USD')`.

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.

regularfry 11y ago

Any value type.

adrianmacneil 11y ago

Another (even more simple than Money) example are many of the standard library classes. For example BigDecimal. With operator overloading, I can easily compare a BigDecimal object to an integer or float, the same way I can already compare them to each other: BigDecimal.new("10.0") == 10.0 10 == 10.0 Without operator overloading, this would become needlessly messy (and require explicit handling of nils): d = BigDecimal.new("10.0") !d.nil? && d.value_equal_to(10.0) Ruby has always been about readability of the code, and avoiding unnecessary repetition, and I think operator overloading (when used correctly) is a great example of this.

waxjar 11y ago

My personal favorite: a safe, constant time equality method for cryptographic stuff.