Timeline for Why didn't == operator string value comparison make it to Java?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 18, 2014 at 5:26 | comment | added | maaartinus | Let us continue this discussion in chat. | |
| Nov 18, 2014 at 5:18 | comment | added | supercat |
@maaartinus: Care to chat? I agree with you that Java allows a number of things that IMHO should be forbidden; it also forbids some things which IMHO should be allowed. I wish languages would include more primitive types for each storage format, depending upon whether types should try to behave like abstract numbers or machine-representable quantities. Should a 32-bit floating-point declaration be viewed as saying "I want to hold an exact power-of-two fraction, or as "I want to hold a real number, but will tolerate float precision"?
|
|
| Nov 18, 2014 at 5:11 | comment | added | maaartinus |
If there's no good solution for the primitive to object comparison, then I'd simply forbid it. It'd be a special rule, but one which could bite nobody. +++ Claiming that int to float is not lossy is one of big Java mistakes (rarely anybody runs into this, but if so, it's pretty hard to find). If they didn't want to special case 1 + 2.0f to return double, then they should simply forbid it; similarly for 16777217==16777216.0f. +++ Also lL + 2.0 should be forbidden, as there's no type to which both operands could converted to without real narrowing.
|
|
| Nov 18, 2014 at 4:56 | comment | added | supercat |
...comparison based upon actual numerical value with either convert both operands to double, or else test if converting the first operand to float yields the second and converting the second to int yields the first. If Java doesn't accommodate special behaviors for mixed-type operators in cases like that, adding it for the less common reference-vs-primitive comparisons would seem less compelling.
|
|
| Nov 18, 2014 at 4:54 | comment | added | supercat |
@maaartinus: If == never tested reference equality, then it could sensibly perform a null-safe value-equality test. The fact that it does test reference equality, however, severely limits how it can handle mixed reference/value comparisons without inconsistency. Note also that Java is fixed on the notion that operators promote both operands to the same type, rather than yielding special behaviors based upon the combinations of types involved. For example, 16777217==16777216.0f returns true because it performs a lossy conversion of the first operand to float, while a...
|
|
| Nov 18, 2014 at 2:04 | comment | added | maaartinus |
I think that my idea is consistent. Just keep it mind that in the better world, == has nothing to do with identityEquals. +++ "separate equality operators for value and reference equality" - but which ones? I'd consider both primitive == and equals as doing value comparison in the sense that equals looks at the value of the reference. +++ When == meant equals, then int==Integer SHOULD do autoboxing and compare the references using null-safe equals. +++ I'm afraid, my idea is not really mine, but just what Kotlin does.
|
|
| Nov 17, 2014 at 16:20 | comment | added | supercat |
...since autoboxing the int and doing a reference comparison would have been silly [but wouldn't always fail]. Otherwise, I see no reason to allow an implicit conversion that can fail with an NPE.
|
|
| Nov 17, 2014 at 16:16 | comment | added | supercat |
@maaartinus: A good language design should use separate equality operators for value and reference equality. While I agree that conceptually it would have been possible to have an int==Integer operator return false if the Integer is null, and otherwise compare values, that approach would have been unlike the behavior of == in all other circumstances, where it unconditionally coerces both operands to the same type before comparing them. Personally I wonder if auto-unboxing was put in place in an effort to allow int==Integer to have a behavior that wasn't nonsensical...
|
|
| Nov 17, 2014 at 8:33 | comment | added | maaartinus |
I must be missing something, but IMHO == on objects should simply call (null-safe) equals and something else (e.g., === or System.identityEqual) should be used for the identity comparison. Mixing primitives and objects would be initially forbidden (there was no autoboxing before 1.5) and then some simple rule could be found (e.g. null-safe unbox, then cast, then compare).
|
|
| Dec 24, 2013 at 19:31 | history | edited | gnat | CC BY-SA 3.0 |
added 2 characters in body
|
| Dec 24, 2013 at 19:24 | history | answered | supercat | CC BY-SA 3.0 |