On Wed, Mar 7, 2012 at 9:45 PM, Michael Dürig<[email protected]> wrote:
Regarding equals in the abstract base classes: I'd make the equals methods
in the abstract base classes final.
No, the current non-final implementation is by design.
See the followup patch I attached to OAK-3 for what I'm aiming at
here. Basically I want to decouple the task of diffing node states
from the underlying storage model (so far the diff() method has been
an integral part of the .mk.model.Node interface).
To do that efficiently, we need a fast way to compare potentially huge
subtrees for equality. The underlying storage model can do that for
example when the states point to the same storage location or have the
same content hash, which is why they should be able to override the
equals() method. Otherwise an equals() check could end up traversing
the entire subtree.
Ok makes sense.
Overriding them in a concrete subclass will most likely break symmetry.
If it does, it breaks the API contract and should be fixed.
Right. I should have read the Javadoc ;-) However, I'd make it more
explicit there, that sub classes must not refine equality (i.e. take
into account values of other fields). This will in almost any case lead
to a broken contract. For example (emphasis added): "Two property states
are considered equal if *and only if* both their names and encoded
values match."
Michael
