L'uguaglianza dovrebbe essere commutativa all'interno di una gerarchia di classi?

Non simmetrico ¹ equals rompe il contratto dell'operazione, chiaramente indicato nella documentazione (sto citando dalla documentazione di Java, ma rimane essenzialmente lo stesso in altre lingue)

The equals method implements an equivalence relation on non-null object references:

• It is reflexive: for any non-null reference value x, x.equals(x) should return true.
• It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
• It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
• It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
• For any non-null reference value x, x.equals(null) should return false.

Queste sono proprietà matematiche che una relazione deve avere per essere chiamata una relazione di uguaglianza. Una relazione può essere definita senza nessuna di queste proprietà ² , ma fondamentalmente non è una relazione di uguaglianza, ed è pericoloso utilizzarla nel contesto in cui è implicita la relazione di uguaglianza.

² Ad esempio, è molto allettante definire l'uguaglianza di float s come "due numeri con la differenza assoluta minore di un piccolo epsilon"; è una pessima idea, perché rompe la transitività.

Non ho mai visto = definito come "è-a". = significa "è uguale a", non "è derivato da", anche nelle gerarchie di tipi e "è derivato da" è generalmente implementato con un diverso operatore o funzione. Dove l'hai visto implementato nel modo in cui descrivi? Perché è contro-intuitivo e solo strano .

La maggior parte dei programmatori non accetterebbe l'idea di "uguaglianza". Chiamerebbero "compatibilità" o "gerarchia di ereditarietà" o qualcosa di simile che descrive più correttamente cosa sta succedendo, ma l'uguaglianza dovrebbe significare "identico", non "compatibile". Quindi sì, dovrebbe essere commutativo.

Penso che la commutatività in una gerarchia di classe dovrebbe essere garantita, altrimenti ciò violerebbe il principio di sostituzione di Liskov (LSP) che dice

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Quindi se prevedi l'uguaglianza (A == B) e inserisci un sottotipo di B, chiamato C per il quale l'uguaglianza non regge (A! = C), causeresti una violazione. Forse (C == A), ma le persone che usano le tue classi potrebbero non aspettarsi questo comportamento.

Ad esempio, voglio usare le tue classi nel mio programma:

public boolean isEqual(B x, B y) {
   return x.equals(y);
}

Dire che ho due istanze, x è di tipo B e y il sottotipo B '. Come posso o garantisco che inserisco gli oggetti nel giusto ordine nel metodo? Ciò comporterebbe molte strutture di controllo aggiuntive. E se non mi aspettassi questo comportamento, sarebbe difficile eseguire il debug.