It also just does not work. You cannot "override" member functions with extension functions. If you use the

==

it will never call an extension function (same if you call

equals

directly), since the

equals

in

Any

always has higher precedence.

As a FYI, my use of

Value.equals(Value): Boolean

is representing the method signature, not a

fun Value.equals(other: Value): Boolean

extension function (granted vague since the primary difference is the absence of

fun

)

Oh. Well, then I retract my statement 😄

Same here

But it still doesn't sound like a great idea at all.

sure. but what if i overload equals 😉

I agree about the overriding. I think the same contract would still exist and be considered during overloads 🙂

I agree. But as the same object might be used by it's real type and in another place as an

Any

, results of different

equal

and

hashCode

might get mixed

If you overload

equals

, you should also override

equals(Any?)

. The latter probably invokes the overloaded variant at some point. This way everything works, and the compiler can still pick the most suitable one, skipping useless

null

and

is

checks

I can see that 🤔 would that be any different than defining

A.plus(a: Any?)

vs

B.plus(b: B)

(given B extends A)

The point is that having a generic (Any) and a specific (Value) implementation of equals seem a bad idea because overload resolution happens on the declare type, not the real type and can be different in different parts of your code. And I think equality should not be relative 🙂

Or more appropriately

compareTo

dispatches to the overloaded methods, but I think greater/less comparisons are just as important as equal value comparisons

Yes, they can be different, but I prefer to be able to choose if I want them to be different or not. So I am still interested in knowing whether the limitation is to prevent confusion (which is seemingly not a problem with other operators), or due to technical restrictions

I am sure there is a OO-Programming text book that would tell us that it is generally no good idea to write more spefic overloads to more generic implementations from a base class

I agree @jstuyts-squins. To me, this seems like either than intentional limitation or an oversight in the consistency of the

==

convention compared to the others

I pledge for 'intentional limitation'

I would pledge for consistency in the way all conventions are dispatched since they are syntax sugar that get converted in the compilation process 🙂 (whether it be overloading or overriding)