[hibernate-dev] [OGM] Option identity
Emmanuel Bernard
emmanuel at hibernate.org
Tue Oct 22 03:42:34 EDT 2013
On Mon 2013-10-21 17:17, Gunnar Morling wrote:
> 2013/10/21 Emmanuel Bernard <emmanuel at hibernate.org>
> So he changed the implementation of Option / UniqueOption to behave like I
> > previously explained for generic options but to properly return
> > ShowSql.equals(ShowSql.FALSE) == false. To do so, he removed
> > getOptionIdentity() and manually ask (Unique)Option implementors to
> > implement equals. In his example equals for ShowSql would be based on the
> > value.
> >
>
> That's not quite right, maybe this already is the source of our
> disagreement. I only removed the final implementation of
> UniqueOption#getOptionIdentifier() (which was based on the specific
> sub-type of UniqueOption). Option#getOptionIdentifier() is still in place.
>
> So an option implementor has to implement getOptionIdentifier() in both
> cases, for unique and non-unique options. He doesn't have to implement
> equals() himself (which is implemented in the Option super-class and takes
> into account the specific option type and the result of
> getOptionIdentifier()).
>
> >
> > So we are at an impasse.
> >
> > I hate his approach as the equals behavior is inconsistent between generic
> > options and unique options. It's very confusing for an Option implementor
> > to figure out what equals should do. And ice on the cake, the implementor
> > has to implement equals / hashCode instead of delegating that to the
> > superclass: more code, more opportunities to screw it up.
> >
>
> As outlined above an option implementor only needs to provide
> getOptionIdentifier(). The only difference to the situation before is that
> he needs to provide that method for unique option types now, too.
>
> Does this alleviate your concerns about the proposed change?
This removes the argument against the overhead of rewriting equals.
Strange that I did remember seeing actual equals reimplementations.
Anyways, no that does not solve my fundamental concern that it remains
inconsistent how you implement getOptionIdentifier between unique and
generic options.
Emmanuel
More information about the hibernate-dev
mailing list