what's the rational behind PushbackSideInputDoFnRunner?
Why not using a DoFnRunner<WindowedValue<InputT>, OutputT>?
It is the same thing I think, better represents what it does (most is
delegated in general) and avoids yet another API which is not even
implemented completely in 1 of the 2 implementation cause the interface is
not relevant for one case (onTimer in ProcessFnRunner).
Worse case we keep the pushbacksideinputdofnrunner interface but extends
the dofn one to avoid to define other methods and we just break the process
method name which is the only one which was not copied (not sure why).
Personally I'd be to drop completely the interface but aliasing the first
one with a default method to bridge the process methods sounds good as well
and allows to reduce the forked code between both branches.
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book