mdedetrich opened a new pull request, #1406: URL: https://github.com/apache/pekko/pull/1406
So I discovered this when using the javadsl within a kotlin project but it appears that many of the stream functions in javadsl are using their curried equivalents (i.e. `limitWeighted(n: Long)(costFn: function.Function[Out, java.lang.Long])` vs `limitWeighted(n: Long, costFn: function.Function[Out, java.lang.Long])`, This appears to be a massive oversight, as not only is this currently entirely inconsistent in the codebase (see fold vs foldWhile in Flow javadsl or fold in Source vs fold in Flow javadsl) but Java has no real concept curried functions and so applying curried functions written in Scala is not idiomatic. There is also the case of `watchTermination` which had a zero arg curried implementation i.e. `def watchTermination[M]()(matF: function.Function2[Mat, CompletionStage[Done], M])`. I don't know if the zero arg was doing anything meaningful (afaik curried function application is strict so its not suspending the future), in any case I added a `def watchTermination[M](matF: function.Function2[Mat, CompletionStage[Done], M])` variant so check if this is indeed correct and I am not messing a behaviour (if the future is meant to suspended in a thunk then we should just use java function). @He-Pin @jrudolph @raboof Maybe you want to have a look at this PR since you are more intimate with the codebase, particularly wrt `watchTermination` and if its arg needs to be suspended or not -- 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: notifications-unsubscr...@pekko.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org For additional commands, e-mail: notifications-h...@pekko.apache.org
