On Mon 2013-10-21 17:17, Gunnar Morling wrote: > 2013/10/21 Emmanuel Bernard <emman...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
