You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to covariance issues with Lucene.Net.Grouping, we changed Collector from an abstract class to an interface. However, we also have a static Collector class that is only used to put constants that are not possible to put on an interface in .NET. We should probably change that static class back to an abstract class that implements ICollector and leave ICollector on all of the methods throughout the codebase. This makes it easier for users who are copying code from Java to implement a collector.
However, we need an analyzer to ensure that none of our internal code actually accepts Collector as an argument.
Do note that we could potentially get rid of the ICollector interface altogether if the GroupingSearch class were divided into 3 separate classes instead of having main Search methods that deal with object closing types. I would really like to get rid of the non-generic IDictionary and ICollection usages in Lucene.Net.Grouping and Lucene.Net.Queries and replace them with generics prior to the release. J2N doesn't fully support non-generic collection interfaces, so it is best not to use them at all.
@rclabo did some analysis in this area and added some tests (as demos), so he would be a big help to accomplish this.
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Task description
Context: #914 (comment)
From @NightOwl888:
The text was updated successfully, but these errors were encountered: