I usually do an explicit check for nulls and that's why I allowed myself to bring the issue up. It's similar to operator priorities -- I just like to have explicit brackets instead of relying on my degenerating memory... As for sorting, I don't like to rely on the default hashCode/equals exactly for the reasons you mentioned and prefer explicit comparators. It's really a pity there is no full hashcode/equals delegation model in java util collections, it would be a nice addition.
On Tue, May 3, 2011 at 10:41 AM, Uwe Schindler (JIRA) <[email protected]>wrote: > > [ > https://issues.apache.org/jira/browse/LUCENE-3058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028109#comment-13028109] > > Uwe Schindler commented on LUCENE-3058: > --------------------------------------- > > :-) It always confuses me, too. But if you think more about it, it makes > sense to return false. But it's the same always for me: Whenever I write > equals() methods, this question pops up. But now I mostly copy code like the > one above from other classes. But you have to note: The above equals() code > is only 100% suitable for final classes, else it could happen that a > subclass that extends some fields is equal. But thats more a theoretical > discussion. E.g. Lucene's Queries always check > this.getClass()==other.getClass(). > > > FST should allow more than one output for the same input > > -------------------------------------------------------- > > > > Key: LUCENE-3058 > > URL: https://issues.apache.org/jira/browse/LUCENE-3058 > > Project: Lucene - Java > > Issue Type: Improvement > > Reporter: Michael McCandless > > Assignee: Michael McCandless > > Fix For: 4.0 > > > > Attachments: LUCENE-3058.patch, LUCENE-3058.patch > > > > > > For the block tree terms dict, it turns out I need this case. > > -- > This message is automatically generated by JIRA. > For more information on JIRA, see: http://www.atlassian.com/software/jira > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
