Hacker News Reader

Comment by regularfry | Hacker News Reader

In its place, being able to redefine equality on value types really helps clarify code. Misused, it creates confusion. The problem is that it's easy to think you've got a case where it helps, when actually it's not well-defined. Usually that revolves around there being state you care about which is missed from the equality comparison.

Another trap is redefining #== without also looking at #eql?, which means Hash doesn't behave like you expect. It's just another bit of mental trivia you've got to Just Know...

View on HN

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.

I think Python make the difference clear, with == vs "is".

Ruby provides object_id for the same purpose. Comparing those for equality provides the "is_" semantics.

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

Lisp does not have 'equals' and 'equals?'.

Lisp has 'eq', which is for object identity. Lisp has 'equal' which checks for structural equality.

and 'equals?'

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')`.

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.

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.

> 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.

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.

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.

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.

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.

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.

Should Money.new(20, 'USD') == Money.new(2000, 'US Cents')?

Or Money.new(20, 'USD') == Money.new(125, 'CNY') when ExchangeRateManager.getExchangeRate('CNY', 'USD') == 0.16?

My point is that when performing these comparisons, it may be useful to use a more descriptive function like:

boolean currenciesHaveSameWorth(Money m1, Money m2)

And then a reader of the calling code might not have to look into the implementation to understand what the function is doing, whereas you definitely would when using == because == now means "whatever it's overridden to mean"

> Should Money.new(20, 'USD') == Money.new(2000, 'US Cents')?

Like someone else pointed out in this thread, designing APIs require consistency and good taste.

If I had to implement this API you code above would evaluate to `ArgumentError unknown currency "US Cents"`.

> Or Money.new(20, 'USD') == Money.new(125, 'CNY') when ExchangeRateManager.getExchangeRate('CNY', 'USD') == 0.16?

Again, me designing this API, it wouldn't be equal. Why? For the same reason `1 != "1"`, if you cast them, yes they are equal, but implicit casting (aka weak typing) is not idiomatic in Ruby, it's possible, but very rare.

> boolean currenciesHaveSameWorth(Money m1, Money m2)

At this point you might as well do `m1 == m2.convert_to(m1.currency)`, because "HaveSameWorth" might mean many different things too.

> At this point you might as well do `m1 == m2.convert_to(m1.currency)`, because "HaveSameWorth" might mean many different things too.

I personally hate that last style because it's obvious that the "HaveSameWorth" relation is intended to be symmetric, and by writing it like m1 == m2.convert(...) you're prefering one side over the other. It looks bad for me :).

Also, in case of real-life objects it makes sense to spell out what do you mean by 'equality' (or 'equivalency'), and leave the default implementation to represent the philosophical concepts of "the same" and "equivalent to".

But you almost certainly are logically preferring one side over the other! You do usdValue == cadValye.convert_to(usdValue.curr) because one of those currencies is the one your transaction is working with (in this case, USD is your goal).

Any value type.

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.

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

Reply on news.ycombinator.com