Object is bloated? That's an odd complaint. Much like array covariance, object was pretty much directly copied from Java.
I disagree on getting rid of Equals if for no other reason it's implicitly used often (like in collections). And if there is no canonical idea of equality, that's what overriding Equals is for, and what Object.ReferenceEquals is for (return yourself to the base notion of equality when you need it).
It's a mistake in Java too. It's often convenient to simply skip implementing equals() and hashCode() because you don't plan to use an object as the key to a map. In that case, attempting to use it as a key should fail to compile, so you know you need to go back and add it.
The Comparable interface shows how it should be done.
(But on the other hand, if you were starting over it would be better to learn from Go's interfaces.)
Uh oh, I wouldn't want anyone to copy anything that has to with typesystem from Go before they tell how they are going to have typesafe containers without generics. Haskell typeclasses would be a better source of inspiration IMNSHO.
His argument is that the concept of equality will vary by application and a default implementation adds very little. For example, does it make sense to test equality on a filestream? Probably not, but it's there and it purports to have some meaning.
This of course, only makes sense in the post-generic world of .net +2.0 so he does excuse their presence as a vestige of 1.1.
But simple equality often does make sense in the context of collections. Am I going to throw filestreams in a collection, probably not, but I very often throw all kinds of objects in a collection and the base object.Equals very often fits my needs there perfectly.
I dunno, I haven't actually watched this presentation so maybe I just need more context. But I've been programming in C# since it came out and not once have I ever had any real issues with Equals and all of its related methods.
I agree that as a practical matter it does what you want a majority of the time but generic collections let you mandate that an author has thought about equality for his object at least a little by implementing IEquatable. Particularly since a default definition of equality doesn't always make sense (as in the case of the fs).
As with the case of explicitly sealed/unsealed classes, it seems like Jon's MO is to make programmers think about some of these things more carefully rather than have a "correct 90% of the time" default; a sentiment which I can definitely appreciate. :)
Anyway, he discusses it at approximately the 36 minute mark. Well worth a look.
Object is bloated? That's an odd complaint. object was pretty much directly copied from Java
What are you saying - that if it was copied from Java, it must be OK? It is not impossible that object is both copied from Java and bloated.
I disagree on getting rid of Equals if for no other reason it's implicitly used often
But it isn't used often. Take an application of yours. What percentage of the types that you have defined in it need to worry about equality over and above ReferenceEquals? You may have collections of customer, but never collections of CustomerFactory, CustomerRepository, CustomerController, CustomerEditForm, etc...
And if there is no canonical idea of equality, that's what overriding Equals is for
If you override equals, you can only have one kind of non-reference equality per type, which is what Jon Skeet says is not always the right thing.
I disagree on getting rid of Equals if for no other reason it's implicitly used often (like in collections). And if there is no canonical idea of equality, that's what overriding Equals is for, and what Object.ReferenceEquals is for (return yourself to the base notion of equality when you need it).