Question

I have read that it is a bad idea to take aliasing into account when implementing equals.
An example would be equals for File.
I was wondering why is it a bad idea? Simply because the implementation is harder to be correct?
If FileA and FileB refer to the same file but have different path names why should they be not equal?

Answer 1

Making equals() return true for aliased filenames that point to the same actual file is a bad idea because it violates common assumptions about the behaviour of equality.

Consider the following examples:

• Even if they refer to the same underlying file right now, this may change in the future (e.g. due to changes on the filesystem making one path invalid). You want things that are equal now to stay equal in the future (unless of course you explicitly mutate them).
• If you transform the files (for example by going up one directory) then the results will also not be equal. The assumption being violated here is that you expect the same operation applied to two equal things to produce equal results.

Hence we can see that taking aliasing into account would produce some unexpected behaviour for two supposedly “equal” objects. This is likely to cause strange and subtle bugs in the future when people make incorrect assumptions.

A secondary but also relevant concern is that taking account of aliasing may add considerable implementation complexity and performance overhead. You normally want equals() to be very efficient since it may get called often: if it is forced to make IO calls to the operating system to determine file aliasing then this is unlikely to be the case.

In this situation I would implement a completely different function that tests for pointing to the same physical file – refersToSameFile or something similar. This allows you to use a more descriptive name for the operation and avoids messing up expectations about equality behaviour.