paulirwin commented on issue #1059: URL: https://github.com/apache/lucenenet/issues/1059#issuecomment-2543446756
> If you think about it, since we are having trouble testing it this way, it is very likely that users will need to be able to store these distinct types in a common variable type (after all, Java allows this), so making this a first class feature rather than a test mock is necessary. I'm not so sure it's necessary, this is only a problem with using the low-level Abstract*Collector types. I don't think many people are going to be using those low-level types (instead using the types in the GroupingSearch file), and those that are further still are probably not going to need to be switching between them in the same variable like the test does, and further still if they really need to do that, they can do a workaround like we're doing here. What I don't want to have to do is expose object-based properties that are shadowed in the generic classes (or worse, i.e. `ICollection<object> Groups` for a non-generic AbstractAllGroupsCollector base class). That seems like a cure that is worse than the disease, and I don't even know if it's feasible. > Would it make sense to add the closing types of IDictionary<TKey, TValue> to the classes that wrap them? It looks like we could cascade that down from AbstractGroupingSearch<T, TKey, TValue> down to the others like AbstractFirstPassGroupingCollector<T, TKey, TValue>, etc. No, because ValueSource implementations treat it as `IDictionary<object, object>`. Different implementations use different types for the keys and values. Object is the only common type. We also don't know which particular ValueSource implementations will be used, so that's pretty much impossible. This dictionary is truly just a bag of key/value pairs, strongly typing it would not help anything and would require a significant deviation from upstream. -- 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 For queries about this service, please contact Infrastructure at: us...@infra.apache.org
