[
https://issues.apache.org/jira/browse/LUCENENET-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067361#comment-13067361
]
Digy commented on LUCENENET-437:
--------------------------------
Java Docs says:
public boolean equals(Object o)
Compares the specified object with this list for equality. Returns true if
and only if the specified object is also a list, both lists have the same size,
and *all corresponding pairs of elements in the two lists are equal* [No
reference for Hashcode - DIGY]. (Two elements e1 and e2 are equal if (e1==null
? e2==null : e1.equals(e2)).) In other words, two lists are defined to be equal
if they contain the same elements in the same order. This definition ensures
that the equals method works properly across different implementations of the
List interface.
Yes, the sample was from Eric Lippert's blog to show why GetHashCode should not
be used for comparing objects.
bq. The issue you're describing is more of a problem with the .NET
implementation of GetHashcode() rather than the correctness of using hashcode
for comparison.
No, the problem is not in the implementation of GetHashCode. In any
implementation, you may have some unexpected collisions(since it is a 4-byte
number). GetHashCode isn't meant for uniqueness or object identification. It's
meant to provide a random distribution.
Therefore the problem really lies in using it for equality comparison.
DIGY
> Port Contrib.Shingle from Java
> ------------------------------
>
> Key: LUCENENET-437
> URL: https://issues.apache.org/jira/browse/LUCENENET-437
> Project: Lucene.Net
> Issue Type: Task
> Components: Lucene.Net Contrib, Lucene.Net Test
> Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g
> Reporter: Troy Howard
> Assignee: Troy Howard
> Priority: Minor
> Fix For: Lucene.Net 2.9.4, Lucene.Net 2.9.4g
>
>
> Port Contrib.Shingle from Java
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
