lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Paldino (JIRA)" <>
Subject [jira] Commented: (LUCENENET-292) Optimization of EquatableList<T>
Date Fri, 20 Nov 2009 17:02:41 GMT


Nicholas Paldino commented on LUCENENET-292:


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

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:

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:
>             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
> Patch to follow.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message