pnowojski commented on PR #21690: URL: https://github.com/apache/flink/pull/21690#issuecomment-1396636736
@lindong28 I don't understand your concerns. With separate functional interface as you are proposing you will have exact same "problems". If you add functional interface to the [AbstractStreamTaskNetworkInput](https://github.com/apache/flink/pull/21697/commits/328510c28779d64fa249c33f6a1014fb7c7f6ddf#diff-68389ccd4de1418caa25baa2429ebdc1040834f5386ecb046acc940c418086ba), you would have exact same issue, that you would need to pass different instances of that interface, that would at the moment return always `false` for multiple input tasks (note IMO that's only a temporary limitation. `MultipleInputStreamTask` could be implemented in the future to allow batching). On top of that, I really don't see this being an issue at all. That's the whole point of code re-usability, regardless if it's object oriented or functional. You want to pass different implementations, that will be behaving differently. > Are you suggesting that we should now couple the caller of DataOutput with the code that constructed it? Caller shouldn't care if it's coupled or not. It should just adhere to the contracts of the instances/classes/functions that are passed to it. And in this case the caller indeed doesn't care at all `SourceOperator` instances are using the same `DataOutput` instance or not. Just use the instance that's passed. For me the only difference between (1) separate functional interface vs embedding the same functionality in (2) the `DataOutput` is that the first one behaviour how the `DataOutput` should be used is controlled and passed independently of it, which hides the connection and increases chances that someone will forget to use the functional interface after some refactor/adding new code. And it's more verbose as you need to pass around two objects instead of just one. -- 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]
