paulirwin opened a new issue, #918: URL: https://github.com/apache/lucenenet/issues/918
### Is there an existing issue for this? - [X] I have searched the existing issues ### Task description Context: https://github.com/apache/lucenenet/pull/914#discussion_r1493348597 From @NightOwl888: > 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
