garydgregory commented on code in PR #784:
URL: https://github.com/apache/commons-io/pull/784#discussion_r2368184174
##########
src/main/java/org/apache/commons/io/build/AbstractOriginSupplier.java:
##########
@@ -368,4 +376,26 @@ public B setURI(final URI origin) {
public B setWriter(final Writer origin) {
return setOrigin(newWriterOrigin(origin));
}
+
+ /**
+ * Sets a new origin.
+ *
+ * @param origin the new origin.
+ * @return {@code this} instance.
+ * @since 2.21.0
+ */
+ public B setReadableByteChannel(final ReadableByteChannel origin) {
+ return setOrigin(newChannelOrigin(origin));
+ }
+
+ /**
+ * Sets a new origin.
+ *
+ * @param origin the new origin.
+ * @return {@code this} instance.
+ * @since 2.21.0
+ */
+ public B setWritableByteChannel(final WritableByteChannel origin) {
Review Comment:
Well, thinking of the Compress use case, the only interface that matters
there is `SeekableByteChannel` which is both a read and write channel as you
pointed out.
>On the other hand, many channel implementations declare both interfaces but
only fully support one.
I don't think we should be concerned about implementations since we are
supporting interfaces here. This feels a bit like `Path` which is an abstract
class but behaves like an interface for call sites. We don't concern ourselves
with the implementations of `Path`.
I would expect specific origins to test for read/write/seekable kinds of
channels and use what they need.
So all of this to say it seems like you should be able to say
`setChannel(Channel)` and getters like `get ReadableByteChannel()`,
`getSeekableByteChannel()`, and `getSeekableByteChannel()` should do their best
or throw.
--
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]
