gildor
09/21/2017, 7:07 AMuli
09/21/2017, 7:29 AM==
-operator to an overload of equals.
The overload (e.g. fun Value.equals(Value): Boolean
) would not be used by any generic code. As pointed out by @gildor, most notably by classes like HashMap.
So you could have two values a: Value
and b: Value
with a == b
yielding true
.
At the same time something like fun <KeyType> keysEqual(a: KeyType, b: KeyType) = (a == b)
, as might be used in a hash map implementation to compare keys, yields false
.
So even though a == b
hashMapOf(a to 1, b to 2)
would yield a map with two distinct elementshashMap
would fire back at you.
So in general, you should probably not overload hashCode
or equals
bdawg.io
09/21/2017, 7:34 AMequals
-hashCode
contract by overriding the equals(other: Any?): Boolean
method which would lead to the same confusion in the existing conventiongildor
09/21/2017, 7:35 AMbdawg.io
09/21/2017, 7:39 AMequals
-hashCode
contract through overloading vs overriding??gildor
09/21/2017, 7:40 AM==
that works as equal
in one case and doesn’t work in anotherbdawg.io
09/21/2017, 7:48 AM>
, <
, etc. with the compareTo
operator in the existing functionalityuli
09/21/2017, 7:51 AMcompareTo
?bdawg.io
09/21/2017, 8:00 AMcompareTo
defined on Any
, but the same scenario can be produced through 2 definitions of compareTo
one for a more generic parameter than the otheruli
09/21/2017, 8:02 AMgildor
09/21/2017, 8:03 AMAny?
contract that used by other parts of Kotlin stdlib or JVMbdawg.io
09/21/2017, 8:04 AMoperator fun Any.compareTo(other: Any?): Any
is a valid extension function that would be used by the compiler in every context it is imported into. I agree that it’s an issue caused by the developer, but I can cause that same inconsistency through the equals
override instead of an overload hahagildor
09/21/2017, 8:07 AMbdawg.io
09/21/2017, 8:11 AMequals
were resolved by overloads. Again, I’m not saying that the language as it exists right now uses overloads for the equals
convention, but rather that I haven’t seen a strong reason why equals
should behave differently from other contentions (even if that means that all conventions use overriding instead of overloading, although my less preferred option). Remember, conventions are just syntax sugar added by Kotlin, so whether or not the JVM/Java uses it is irrelevant since the compiler transforms to a .compareTo
or a .equals
method callkingsley
09/21/2017, 8:22 PMval foo: Value = ...
val bar: Value = ...
val foobar: Any = bar
println(foo == foobar)
What version of equals would you expect the compiler to pick here?
The equals(Value)
or the equals(Any?)
Remember, equals
has very specific rules guiding it, and deviating from that introduces inconsistencybdawg.io
09/21/2017, 9:41 PMequals(Any?)
. The same issue exists with println(foo > foobar)
.