-
Notifications
You must be signed in to change notification settings - Fork 653
BREAKING: Remove covariance and LINQ use from Grouping, #1059 #1066
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
48fd06f to
ffceff5
Compare
|
This old PR has been rebased against latest main. I intend to merge this this coming weekend if there is no further feedback. |
NightOwl888
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a full review, but there are some old comments that I had in a draft that I am posting so they aren't lost.
There was one issue I found on the first pass where it would have made sense to make a method into an extension method so it could expose the underlying type, but I was unable to locate it when I went back to find it again. I am hoping to locate it while this is still a PR.
This is going to take some dedicated time for a full review, though.
This still needs XML doc comments, but this breaks the GroupingSearch "god class" into three subclasses that implement a common abstract class. This should allow us to not need covariant interfaces for the return types. In order to randomly switch between these classes with incompatible generic type arguments, the test shows how you can use a delegate to work around this limitation.
…ionGroupingSearch<T> class
…s, one failing test
9849a70 to
f0d186b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR removes covariance and LINQ usage from the Grouping module to align with the original Java code and improve performance. The main changes involve:
- Converting generic covariant interfaces to non-generic interfaces with explicit implementations
- Replacing
IEnumerable<T>withICollection<T>/IList<T>for better performance - Adding casting adapter classes to bridge type conversions
- Breaking
GroupingSearchinto specialized subclasses
Reviewed Changes
Copilot reviewed 30 out of 31 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
Support/CastingSetAdapter.cs |
New adapter class for type-safe casting between set types |
Support/CastingListAdapter.cs |
New adapter class for type-safe casting between list types |
Support/CastingEnumeratorAdapter.cs |
New adapter class for type-safe casting between enumerator types |
Support/CastingCollectionAdapter.cs |
New adapter class for type-safe casting between collection types |
Tests |
Updated test files to use concrete types instead of covariant interfaces |
Grouping |
Refactored interfaces to be non-generic with explicit implementations |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
…nly struct to reduce allocations
Removes the covariance and LINQ use from Grouping, breaks GroupingSearch into subclasses
Fixes #1059
Description
See #1059 for rationale. This PR breaks GroupingSearch into three child classes (with some abstract base classes for common configuration properties) so that we can remove the covariance in the interfaces that were added to get this working in the original port. This keeps most of the interfaces but makes them non-generic (and thus, not covariant) for cases where you might need to have them in a common variable or collection. These were also needed for usage in the tests, where the test code randomly switches implementations that otherwise would not have common generic type parameters.
LINQ was removed, and
IEnumerable<T>was changed toICollection<T>/IList<T>to match the original Java code. This should improve performance a little bit by being able to reference Count etc. directly.