NightOwl888 commented on issue #1201: URL: https://github.com/apache/lucenenet/issues/1201#issuecomment-3392934574
@Jivi-this-side Thanks for volunteering. I have assigned this issue to you. Yes, your understanding of how to address the issue is correct. As I previously mentioned, there are some cases where we are accepting a collection interface through the constructor which is the best way we can support both BCL and J2N collection types. In those cases we won't be able to replace the private fields. However, in most cases these collection are instantiated internally, so replacing the field type is fine. I could be wrong, but I am pretty sure that the CA1859 rule is smart enough not to suggest this when the type is set from the constructor. Ideally, this would be a subtle change that doesn't deviate too far from the upstream code. If you find that replacing one tends to involve more plumbing than just changing the field type, it might be a good idea to check with us to determine if there is a better approach. Also, note that we have extension methods on the collection interface types. In most cases, these are passing the call through to the underlying collection. However, there may also be cases where the collection API doesn't exist in .NET Framework or .NET Standard. If you run into that issue, let us know, as that may require more analyisis. This task also should ideally not change any collection types. We mostly use collections from J2N. This is intentional because of various behaviors that they have (such as structural equality) that Lucene or its tests depend upon. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
