Autoboxing

Sutherlands

@Sutherlands said:
@RaceProUK said:
Equals() will always do a reference comparison unless overridden.
And it's overridden for the basic types, so I'm not sure what your point is.

My point is, unless there's an override of Equals() that fits a certain scenario e.g. Int32.Equals(Int64), then you'll get the default, which is a reference comparison.
Do I really have to describe virtual methods to you?

Yes, oh wise one. Please describe how virtual methods work to me. When you're done, please tell me why "Equals() will always do a reference comparison unless overridden." is a valid critique of a post that is providing answers to a bunch of different ways to compare values where in every single case, the overloaded operator is being called. In not one single case do you get the default comparison. Not a single one.

object i1 = 10;
int i2 = 9;
i2++;

ReferenceEquals(i1, i2).Dump();
object.Equals(i1, i2).Dump();
i1.Equals(i2).Dump();

Gives False/True/True

RaceProUK

@Sutherlands said:

Yes, oh wise one

I'm not going to do your thinking for you. However, I did double-check the docs for Equals(), and it seems to be different to what I remembered, making my original post null and void. So enjoy your little victory. Meanwhile, I'm going to be slightly miffed I can't edit my original post, then get on with something important, like checking Twitter.

eViLegion

@RaceProUK said:

...checking Twitter...

You've already lost.

RaceProUK

@eViLegion said:

@RaceProUK said:
...checking Twitter...

You've already lost.

That's OK, I don't mind losing:)

leonardo_

I like the explanations on the SO page... especially the guy who references Postel's Law: Robustness Principle

Then again, I've read a great critique of this principle on the old Joel on Software: Martian Headsets

The JoS article is a classic, in my opinion, at illustrating the ways your customers/users/implementers constrain you (without you knowledge or intention) by using your tools in unintended ways (and then relying on you to not break those 'undocument features').

antiquarian

@Ben L. said:

Go doesn't have boxed numeric types, but you can make one if you REALLY want to.
// NEVER FUCKING DO THIS
type MyInt32 struct {
   Number int32
}

I knew as soon as I saw your username that your post would include a stupid Go code sample. Go ~~play in traffic~~ program in Ada.

Ben L.

@blakeyrat said:

@Ben L. said:
We have interfaces for that shit. If your program requires the use of primitives in a data structure but you don't know what primitives it'll use, YOU are TRWTF.

Because nobody would use something like JSON!

JSON has only one numeric primitive: Number. It also has the complex types String, Object, and Array.

Would you like to try again?

TheCPUWizard

@blakeyrat said:

@joe.edwards said:
It is if you box them.
object testInt = (Int32)29; object testInt2 = (Int64)29;

Ok prepare to call me the real WTF, but I thought Int32 was the boxed version of int and Int64 was the boxed version of long.

NOPE... "int" and "long" are simple "language specific syntactic sugar" over the actual types which are System.Int32, et. al...

blakeyrat

@TheCPUWizard said:

NOPE... "int" and "long" are simple "language specific syntactic sugar" over the actual types which are System.Int32, et. al...

Wow you only spent 3 days in the hibernation chamber this time, that's a new record. Usually people are in there for years.