NightOwl888 commented on issue #832: URL: https://github.com/apache/lucenenet/issues/832#issuecomment-1863707573
@ljcollins25 We have considered that approach for char sequences. In Java, `String`, `char[]`, and `StringBuilder` all implement the `CharSequence` interface, but in .NET there is no common interface between them (and we should also deal with `ReadOnlySpan<char>`), so it was up for consideration. But ultimately we decided against such an approach due to the confusion it may cause - if an API says it accepts a `CharSequence` struct, it may not be obvious that you can pass in a string. Besides, `ReadOnlySpan<char>` now implicitly converts both `String` and `char[]`, which is far more intuitive to use. However, being that we are only passing in `FileInfo` and `DirectoryInfo` to match the Java API and they ultimately are just allocations we don't need because `FileStream` and other downstream APIs don't accept them as parameters, we have to read out the strings to concatenate, etc., they aren't really needed in .NET. We only want to keep these overloads around to match Java Lucene. That being said, `FileInfo` and `DirectoryInfo` do more than just allocate memory. When the string is passed into the constructor of `FileInfo` and `DirectoryInfo`, it is resolved to handle relative paths and symbolic links. However, this logic is also exposed in .NET publicly as static methods, so we still can eliminate the allocations without changing the behavior, it just takes a bit more work analyzing what is going on when `FileInfo` and `DirectoryInfo` are used and duplicating it for the string overloads. Sure, we could handle that in a custom struct to make our job easier, but IMO it makes the end user's job harder, which is not worth the tradeoff. -- 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
