[
https://issues.apache.org/jira/browse/LUCENENET-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780652#action_12780652
]
Nicholas Paldino commented on LUCENENET-292:
--------------------------------------------
Andrei,
Yes, I made the code so that it behaves as the ArrayList class in Java, where
== is a reference comparison. That was reflected in the patch a while ago
after you first commented.
You are right in the sense that when you override Equals, you MUST overload
GetHashCode. However, you are incorrect in saying that == is a reference
comparison operator. When == is not overridden, yes, it is a reference
operator, but in .NET, that is not the intention.
The design guidelines for .NET since 1.1 have indicated that when you override
Equals, not only should you override GetHashCode, but you should also override
==, that they should do the same thing.
See the section of the MSDN documentation titled "Implementing the Equals
Method" located here:
http://msdn.microsoft.com/en-us/library/336aedhh(VS.71).aspx
Also reference the section of the MSDN documentation "Design Guidelines for
Class Library Developers", specifically the section titled "Guidelines for
Implementing Equals and the Equality Operator (==)", located at:
http://msdn.microsoft.com/en-us/library/7h9bszxx(VS.71).aspx
Both say that in .NET, when overriding Equals, you override the == and !=
operators as well.
Note I am not saying that right now that this should be done, but when the code
is made to be more ".NET-like", these operators should be exposed to adhere to
best practices (they are currently commented out).
> Optimization of EquatableList<T>
> --------------------------------
>
> Key: LUCENENET-292
> URL: https://issues.apache.org/jira/browse/LUCENENET-292
> Project: Lucene.Net
> Issue Type: Improvement
> Reporter: Nicholas Paldino
> Priority: Minor
> Attachments: EquatableList3.patch, SupportClass.patch
>
>
> When comparing two IEnumerable<T> implementations, a shortcut can be taken to
> check to see if both IEnumerable<T> expose operations which returns a count
> of items (sequences cannot be equal if the number of elements in the
> sequences are not equal).
> Typically, in .NET, this is expressed through the implementation of the
> ICollection or ICollection<T> interface.
> Before enumerating through each element and comparing the two for equality,
> if the counts are accessible, they should be compared to see if the number of
> elements in the two sequences are equal. If a comparison is able to be made
> before enumerating, it will be much more performant for comparisons of
> sequences where each is ~N, but both are not equal to N, and N is very large.
> Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
