uschindler commented on a change in pull request #643:
URL: https://github.com/apache/lucene/pull/643#discussion_r802870829
##########
File path: lucene/core/src/java/org/apache/lucene/util/IOUtils.java
##########
@@ -526,4 +526,17 @@ public static void fsync(Path fileToSync, boolean isDir)
throws IOException {
public interface IOFunction<T, R> {
R apply(T t) throws IOException;
}
+
+ /**
+ * A resource supplier function that may throw an IOException.
+ *
+ * <p>Note that this would open a resource such as a File. Consumers should
make sure to close the
+ * resource (e.g., use try-with-resources)
+ *
+ * @see java.util.function.Supplier
+ */
+ @FunctionalInterface
Review comment:
> I'm leaning towards class-per-file convention as well. Too many nested
(public) classes makes my head spin.
I think this depends on the use case. If the functional interface should be
used by many classes throughout Lucene's API, I agree with that.
The ones in IOUtils were originally only meant to be part of method
signatures inside IOUtils. In this case, it is better to hide them inside the
IOUtils class, because nobody would refer to them in import statements! You
call a method in IOUtils and use the functional interface implicitely, the name
does not matter as you never import or use the interface name directly). But as
soon as many APIs like kuromoji use the functional interface, then it is better
to place them as top-level classes. Full agreement.
I think that happened with IOUtils: At beginning the interfaces were meant
as method parameters to some methods only, but now they graduated to top-level
citicens.
--
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: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
