4 ms·
The only thing .net could have done differently was to make Equals and GetHashcode into interfaces and perhaps included some best practices. == is there for le
by hvidgaard 10y ago
The only thing .net could have done differently was to make Equals and GetHashcode into interfaces and perhaps included some best practices.
== is there for legacy reasons, and meaning reference equality with the ability to overload it, seems like a reasonable compromise for object types. What we're missing is the ability to create custom value types, that consist of other value types. We already know that it's working with F#, so the CLR does support it. Question is if C# the language can be extented with it.
- emn13 10y ago.net could have made equality entirely optional; and it could have exposed machinery to implement equality (including all aspects of it!) by composition, not manual fiddling - at least not by default! That would have made .net less memory-hungry, faster, less bugprone, and simpler. There's absolutely no good reason for this horribly complicated and inefficient state of affairs; not all platforms/languages suffer from these limitations. As you point out, even F# manages to do better despite the considerable extra limitation of needing to maintain some sort of compatibility even at runtime with the current crazy state, and despite what is certainly a much more limited development budget.
- hvidgaard 10y agoIn hindsight there is a lot they should have done differently. Immuteable by default and not nullable by default are two of the obvious. But they where targeting Java developers, so they couldn't just bring a completely different language to the market. They had to be a better Java.
- alkonaut 10y agoYes Equals and GetHashCode should have been in an interface. After 13years of full time .NET it's the only thing I repeat over and over to newer devs: don't override equals and hash code . Use explicit comparers in your dictionaries because equality is rarely property of your THING, it's a property of the use case. I'd prefer the noise of having to always pass an explicit comparer to a Dict constructor, just for clarity. A similar but related thing they got wrong was the possibility to format strings without an explicit formatter. The result of this? Run all unit test suites for all C# projects on a French/Swedish machine (decimal comma) and I can guarantee that most that involve any kind of formatting will fail because of it. I'd be delighted if they changed this behavior, breaking compatibility with every single C# program ever written, that's how bad it is.
- hvidgaard 10y agoYou don't have much say in Equals and GetHashCode when using objects for for instance ItemSource for a ComboBox. But it's not that bad, you just need to have a senior dev sign off the implementations.
- alkonaut 10y agoA Control that does comparisons isn't much different from any other class that does internal comparisons- just like for a Set or Dictionary. If objects didn't have a default Equals/GetHashCode then all constructors for Dictionaries (And combo boxes) would take an IEqualityComparer argument.
- hvidgaard 10y agoIt does complicate things quite a bit because WPF declares things in XAML, and giving constructor arguments is a major pain. You could make it a DependencyProperty, but it's still convoluted.
- alkonaut 10y agoI'm sure it's already possible and you could make the call default implicit so if you don't pass an equality comparer it just uses DefaultParer.Instance which does what the current default (object) comparer does.