accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Havanki (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1627) Add hashcode() and equals() to ConditionalMutation
Date Tue, 24 Sep 2013 20:13:03 GMT


Bill Havanki commented on ACCUMULO-1627:

It's tricky to implement {{equals()}} in a subclass ({{ConditionalMutation}} being a subclass
of {{Mutation}}), especially since the former adds significant fields. It boils down to the
old {{instanceof}} vs. {{getClass()}} debate. Currently, {{Mutation}} uses {{instanceof}},
but none of its subclasses really address implementing {{equals()}} currently.

I'm inclined to go with {{getClass()}} for defining {{equals()}} in this hierarchy. This will
preserve the {{equals()}} contract but violate the Liskov substitution principle (i.e., a
{{ConditionalMutation}} object won't ever equal a {{Mutation}} object with the same common
fields, and vice versa, so you couldn't use one to find the other in a set, say). I think
in this case that's OK.

However, I absolutely would love input from the experienced committers and contributors on
this decision. I could implement it either way.

> Add hashcode() and equals() to ConditionalMutation
> --------------------------------------------------
>                 Key: ACCUMULO-1627
>                 URL:
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: client, tserver
>            Reporter: Keith Turner
>            Assignee: Bill Havanki
>              Labels: newbie
>             Fix For: 1.6.0
> ConditionalMutation should define equals() and hashcode() methods that consider the conditions.
  Its parent class defines those methods, so it should.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message