I think you refer to the BigDecimal equals which takes the scale into account whereas the compareTo looks at the actual value ignoring scale differences.
Regarding hashcode: There we could use annotations on the properties that contribute to the compare method. You could also have an additional hashCode(ob) on the Mixin thats called when available? Michael Niclas Hedhman schrieb: > On Fri, Aug 22, 2008 at 10:02 AM, Rickard Öberg <[EMAIL PROTECTED]> wrote: > >>> 1. Rickard's suggested "Property Marker" annotation. >>> 2. Equals being called on the Mixins, any one returning false --> notEqual >>> 3. Comparator that somehow have access to the internal state of Mixins. >> How about if the Composite implements java.lang.Comparable, we route >> equals() to that? > > Actually, back in my head there is something yelling about > Comparable/Comparator vs equals() problems, but can't recall what. > > One thing of the pair that doesn't work is the hashCode() bit, as the > contract requires; If a.equals(b) then a.hashCode() == b.hashCode() > And for that we can't use Comparator/Comparable. > > Cheers > Niclas > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
