RE: Equality vs Sameness

Dale <dale0973@xxxxxxxxxxxxx> wrote:
> Good call on my misuse of overriding vs overloading.
> 
> And I agree about overloading == for strings.  The MS guidelines for 
> overloading operators do suggest overloading == for strings and other 
> reference types that act like value types.  So maybe "any" was too strong of 
> a word.  But between you and me, I can't think of a reason to overload == for 
> a string.  I guess it just hasn't come up in my experience.

So you find:

if ((x==null && y==null) || (x != null && x.Equals(y)))
or
if (object.Equals(x, y))

as easy to read as

if (x==y)

?

That's the only real reason - readability. Personally, I think that's a 
really big, good reason.
 
> So, *grin*. let's heat things up and get to the last item... Overriding 
> Equals and GetHashCode.
> 
> I agree about not writing code that hasn't been asked for.  Developers 
> shouldn't add operations to a class because they think the user would benefit 
> from it in the future if the users haven't asked for that functionality.  But 
> while that applies to business logic, there are basic functionality expected 
> in objects that I always include.  

Always? So you override Equals and GetHashCode even for forms, web 
pages, singletons etc? How often have you seen a Form used as the key 
in a hashtable, or wanted to compare two instances of a singleton?

Just looking through my miscellaneous utility library... how often 
would you want to compare instances of threadpools other than by 
reference? Hash-creators? Binary diff decoders? Bit converters? Binary 
readers? The only thing in my library where it makes sense to compare 
instances is Utf32String, which of course *does* override Equals and 
GetHashCode (and overloads ==).

> For instance, I never create a CollectionBase based class and leave out 
> IndexOf or Contains just because when I create the class I don't know if it 
> will be used.  It is a collection and all developers on the team will expect 
> the collections I create to have that functionality without having to put in 
> a change request to get it.

They could easily create the functionality if it's needed though. 
(Personally I never create CollectionBase based classes anyway...)

> I am the same way about Equals.  If you have a custom collection for your 
> class, IndexOf, Contains, and many other methods require value equality, not 
> referential equality, in order to work.  If your class implements IComparable 
> so you can sort it, you have to override Equals as well.

And that's fine for classes where it makes sense to compare instances - 
but in a lot of cases it doesn't. I'd say that fewer than half of my 
objects make sense to compare with other instances - that's a lot of 
work to do for the other half just for the sake of consistency.

Using dependency injection, these days for many of my classes only a 
single instance will ever be created. There's nothing to *stop* new 
instances being created, but they just won't tend to be. Why would I go 
to the hassle of overriding Equals and GetHashCode for those classes?
 
> It's just my opinion but, to me, overriding Equals is a good practice and 
> time well spent in any class except the most trivial or those with very 
> specific functional limitations that would make them exceptions

To override them you have to:

1) Write unit tests for all the different possibilities (checking null, 
checking that each appropriate field is used in the equality, etc)

2) Write the implementation

3) Keep the tests and implementation up to date

Point 3 is the biggest, in a way - how sure are you that if you add a 
field later on, you *always* remember to update Equals and GetHashCode? 
If you don't, you end up with a class which provides a sort of version 
of the functionality desired (if it *is* actually desired).

Do you think MS should have overridden Equals for FileStream? If so, 
what should it have done? How about Thread? 

It's not unreasonable to override Equals and GetHashCode for types 
which will reasonably compared for value equality - but that's *far* 
from all of even most types, IME.

Even where it would *potentially* be useful, I wouldn't usually bother 
until it's needed - but it depends how much bureaucracy is required in 
order to change something later. In my situation, when someone needed 
equality, they could implement it themselves with little more effort 
(if any) than if I'd done it in the first place. Embrace change :)

-- 
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Comparing Array Objects
    ... > However, on a side-note, when realizing a ValueType class, like a struct ... >> The real reason is that Array doesn't override the Equals method ...
    (microsoft.public.dotnet.framework)
  • Re: override GetHashCode
    ... "Stoyan" wrote in message ... > "Derived classes that override GetHashCode must also override Equals to ... > Does any one know, why we must also override Equals, ...
    (microsoft.public.dotnet.framework)
  • Re: do I need to override the equals() method?
    ... be able to compare two objects of my class i.e. to check if they are ... you might want to override equals. ... otherwise some of the standard collections ...
    (comp.lang.java.programmer)
  • Re: Compare Two Identical Datatable By Content
    ... Even if you override the operators the ... public static bool operator!= ... public override bool Equals(object obj) ... compare the schema. ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: Equality vs Sameness
    ... Good call on my misuse of overriding vs overloading. ... reference types that act like value types. ... I am the same way about Equals. ... you have to override Equals as well. ...
    (microsoft.public.dotnet.languages.csharp)
Loading