Re: Who's HOFs on first?
Naftoli Gugenheim <[email protected]> Wed, 11 Nov 2015 13:36:44 +0000
| Newsgroups | gmane.comp.lang.scala |
|---|---|
| Message-ID | <CANpg8PAoE1+2r6vyrbYKuw4S+GDJQdVR7xnPDe502PdfLrP7=w@mail.gmail.com> |
https://github.com/ReactiveX/RxJava had to solve this, you may want to investigate their approach. On Tue, Nov 10, 2015 at 2:51 PM Michael Bayne <[email protected]> wrote: > I'm working on a library that aims to be usable from various JVM languages > (Scala, Java, Kotlin, eventually more), and the API contains higher-order > functions. Ideally I'd like such calls to use the "natural" expression of > HOFs for each language and not require the use of adapter functions. > > There are two routes that seem appealing: > > 1. Use Scala's FunctionN types and hope that the roadmap entry "Turn > FunctionN into Functional Interfaces, so that Java 8 code can call > higher-order methods in Scala without a wrapper." eventually happens. > > 2. Use Java's Function/Predicate etc. types and hope that eventually all > of the situations where code works with Scala functions but doesn't work > for SAMs eventually get ironed out. (This is the approach I tried initially > and then backed out of because it was making the library too annoying to > use from Scala.) > > I couldn't find an issue in JIRA tracking the progress of #1, nor any > information about it on the Interwebs other than the single line in the > roadmap, so maybe even considering that option is foolish. > > I'm just seeking advice, from anyone who is in the trenches on this front, > on which is likely to be the approach least fraught with pain and > frustration (I'm already deeply aware of the reality that trying to write > non-trivial code for use by multiple JVM languages is a road paved with > pain and frustration, so I'm not pointing fingers here). > > Thus far, I've managed to achieve the worst of both worlds by having > overloaded versions of HOF-taking methods, one with Scala's function types > and one with Java's. Java and Kotlin are fine with that because Scala's > types are not SAMs and so they ignore them, but scalac freaks out about > this in a wide variety of circumstances. I'd prefer to move away from this > approach so that my (written in Scala) library is not annoying to use from > Scala. > > Thanks! > > -- [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "scala-language" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "scala-language" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.