@toface said:
Consider the following example:
Double a = 1.0;
Double b = 1.1;
Integer c = 1;
boolean d = a.equals(c);
boolean e = b.equals(c);
boolean f = a.equals(b);
Should d, e or f evaluate true? There are other worse examples, but I consider the strong type safety of Java one of it's strong points. I'm not so sure about autoboxing though..
True, false, false in C#, like you would expect. It casts the integer to a double to do the comparison.
@toface said:
C# never had any momentum before 2.0, so for MS it was a small cost to break backwards compatibility.
Citation needed@toface said:
10 years later it's easy to say that it makes it easier to do a mistake, but I still think they made the right one.
Well that makes 1@toface said:
This can't be considered a big issue anyway, since most static code analysis tools will find this one for you.
Yes, it can. Not everyone uses static analysis tools, and it is obscure and obviously causes bugs. The language CAUSES bugs.
@blakeyrat said:
Huh. Ignorance fought. Thanks. (Just to be a zealot) but the basic point: "I never have to worry about this particular quirk" still applies for C# since, as it turns out, I guess I've never really had to box anything ever. Not that I can recall.
Interesting note - if you have a generic type and use it 100 times for classes, only 1 set of IL will be generated. But each and every struct you put in it has to generate a new set of IL so that it doesn't have to constantly box/unbox them.
Also, the problem here is really that Java doesn't automatically cast numbers to the larger type (like C#).
@joe.edwards said:
It is if you box them. object testInt = (Int32)29;
object testInt2 = (Int64)29;
if (testInt != testInt2)
{
Console.WriteLine("poopity poo");
}
Which is what is happening in the Java sample as well.
Except that ((long)29).Equals((int)29) is true in C#, which I don't believe Java does. Also, C# has a way of working around this, by having real generics.