DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=36527>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36527 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From [EMAIL PROTECTED] 2005-09-07 00:19 ------- The fact that the internal state is different does not in itself imply that the equals() method should return false. Two objects with different field values can be considered equal. There's nothing in the contract for equality that says two equal objects must have bit-per-bit identical representations. Here I think there are two strong reasons to make 1/2.equals(2/4). The first is the obvious natural mathemtical reason. Users naturally expect that 1/2 equals 2/4. The second is the consistency with compareTo. Breaking this shouldn't be done without a really good reason. Is there such a reason? i.e. is there some use case that depends on 1/2 != 2/4? If not, or if the use case is not compelling enough, I think we shoudl consider revising the behavior of the equals() method. If there is such a use-case, then we need to consider revising the behavior of the compareTo() method to make it consistent. Perhaps we could consistently resolve conflicts based on the size of the denominator. For instance, 3/6 > 2/4 > 1/2. However, that's pretty weird and I'd really prefer to fix equals instead. (Plus something's tickling the back of my brain, saying there's some deep mathematical reason that scheme isn't going to work. I'll have to pull out my old number theory books and look up well-ordering.) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
