Niclas Hedhman wrote: > On Fri, Aug 22, 2008 at 8:38 AM, Richard Wallace > <[EMAIL PROTECTED]> wrote: > >> That sounds good. But I'm curious about still adding extra behaviour to it. >> For instance, for this Amount composite I'm thinking that it would make >> sense to have 1km == 1000m return true. But if the examination was only >> done on the plain values of the properties this would be false because the >> unit and value differ. > > When I was heavily involved in measurements of the real world, I also > concluded that equals() is actually too simplistic. > > For instance; 2.34382 is equalTo 2.349123 if the resolution is 1%. As > you have noted, unit and scales matter (sometimes!), -17.778 Celsius > equalsTo 0 Fahrenheit, 0.0254 equals 1 inch, and so forth. > > When was part of a small team to create a control system oriented > programming language, we even had dedicated hardcoded function > "CompareWithTolerance", which was the only equals comparison one could > do on float point values, > > if cmpt( 0.02, abc = def ) > > So, I think that we should have a 3 pronged support for equals() in Qi4j; > > 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? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
