Added function converter capability. #39
Conversation
|
@Ichoran The build failure is due to the lack of quasiquotes in Scala 2.10. I'm going to drop 2.10 support at this point in a separate PR, so we can disregard those. |
|
I'd like to the approach to implicit priorities documented and tested. Here's one example that remains ambiguous: |
|
@retronym - Hmm, I hadn't anticipated that (but should have). It's breaking the most-specific-type part of the computation. But then because of the inversion of specificity due to covariance of function arguments, I wonder whether I need the prioritization at all? I'll play around with it this weekend. I agree I need tests and docs. I don't recall why I pushed this before writing them--maybe I wanted feedback? (Thanks!) |
|
Hmm, I hadn't anticipated that (but should have). Contravariance of function arguments makes things trickier than usual. I might need to add some type identity computations to get it to work. I'll work on it this weekend. (Also--I know I need tests and docs. I think I might have pushed this because I wanted feedback?--I don't recall. Anyway, thanks!) |
…from Jason Zaugg. If you have something from java.util.functions, you should be able to ``` import scala.compat.java8.FunctionConverters._ ``` and then use `.asScala` to convert to the corresponding Scala function. If you have a Scala function, use `.asJava` to convert to the best-matching item from java.util.functions. If you want a function that isn't the best match, use the corresponding `asJavaInterfaceName` method, e.g. ``` asJavaUnaryOperator((i: Int) => i+1) // Best match would be IntUnaryOperator The code is created with a code generator that needs to run in Scala 2.11+, but SBT runs 2.10 by default. Thus, build.sbtt was reworked to be multi-module (the sub-module is the code generator).
These were written manually to avoid making the same assumptions in code generation for the converters and the tests, and thereby missing important bugs. As a downside, though, they do not have complete code coverage. This should not matter given how the code generator works, but it is a weak point.
Ichoran
force-pushed
the
sam-function-compat
branch
from
d180fc5 to
a685a15
Compare
|
@retronym - I did a fairly extensive reworking of the PR, and added tests. I think this is now a decent candidate for inclusion (after appropriate review and modification). |
|
Continued in #48 |
Based on initial reflection work from Jason Zaugg.
If you have something from java.util.functions, you should be able to
and then use
.asScalato convert to the corresponding Scala function.If you have a Scala function, use
.asJavato convert to the best-matching item from java.util.functions.The code is created with a code generator that needs to run in Scala 2.11+, so build.sbt was reworked to be multi-module (the sub-module is the code generator).