SD-121 Remove now-unneeded J{Function,Proc}N functional interfaces #5298
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
retronym
changed the title
retronym
changed the title
Non specialized functions can directly use `scala.FunctionN` as the
functional interface, now that mixin generates default methods in
the new trait encoding.
Unfortunately we can't do this for specialized functions as things
stand: specialization leaves the wrong method abstract. In principle,
we could/should amend the specialization transform to fix this. But
my earlier attempts at this weren't sucessful, so for now we have
to stick with the fallback plan of keeping some hand rolled functional
interfaces around.
This commit reduces the surface area of `scala.runtime.java8` to
the minimal requiremnt: one functional interface for each specialized
variant of `Function{0,1,2}`.
|
LGTM, cool! |
|
Unfortunately this removes |
|
Another issue: We lose serializability of lambdas once again. JFunction* classes were Serializable, scala.Function* classes are still not. |
szeiger
added a commit
to szeiger/scala-java8-compat
that referenced
this pull request
Aug 29, 2016
- Add the required `override` modifiers to trait methods that now extend default methods of Java interfaces. - Add casts in some of these methods because the Scala primitive types are not compatible at the type level with the (now inherited) Java boxed types. - Use the boxed JFunction types in BoxingTest because the generic ones do not exist anymore. - Tests in LambdaTest need to be commented out because usage from Java changed significantly after scala/scala#5298 but we can still cross-build the actual library against 2.11 and 2.12.0-M5. At some point we should consider branching.
|
Maybe we should leave those concerns to Scala-java8-compat and leave things here minimal |
|
Scalac adds serializability to anon classes without the need for the functional interface itself to extend serializable. |
2 tasks
szeiger
added a commit
to szeiger/scala-java8-compat
that referenced
this pull request
Aug 31, 2016
- The various JFunction and JProcedure sources that were removed from Scala in scala/scala#5298 are now included here when building for Scala 2.12.x (except M5). - Code that relies on specialized JFunction types being subtypes of the generic JFunction types will inevitably break. This is unavoidable. The specialized types are still part of Scala but they extend Scala function types directly. - All JFunctionN types and JFunction.func methods are deprecated. They are provided for source compatibility between 2.11 and 2.12 only. - The JProcedureN classes, JFunction.funcSpecialized methods and JFunction.proc methods are still useful in 2.12 for easy interoperability between Scala specialization and Java’s primitive types from Java code.
szeiger
added a commit
to scala/scala-java8-compat
that referenced
this pull request
Sep 9, 2016
- The various JFunction and JProcedure sources that were removed from Scala in scala/scala#5298 are now included here when building for Scala 2.12.x (except M5). - Code that relies on specialized JFunction types being subtypes of the generic JFunction types will inevitably break. This is unavoidable. The specialized types are still part of Scala but they extend Scala function types directly. - All JFunctionN types and JFunction.func methods are deprecated. They are provided for source compatibility between 2.11 and 2.12 only. - The JProcedureN classes, JFunction.funcSpecialized methods and JFunction.proc methods are still useful in 2.12 for easy interoperability between Scala specialization and Java’s primitive types from Java code. - Generate JFunction and JProcedure sources: Just like for 2.11, we generate the sources again for 2.12 (after M5). I wrote a new code generator which is much simpler than the old one (because there is less and simpler code to generate). We can remove the old one when we drop support for Scala 2.11. - Move code back from scala.runtime.java8 to scala.compat.java8: The standard library contains some specialized JFunction* classes in scala.runtime.java8, so we cannot use the same package here if we ever want this to work with Java 9 modules. Therefore everything is moved back to scala.compat.java8 where it was in 0.7. We have to drop compatibility with Scala 2.12.0-M5 which contains these classes as part of scala-library in scala.runtime.java8. - Update to proper Scala 2.12.0-RC so we can build a release
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Non specialized functions can directly use
scala.FunctionNas thefunctional interface, now that mixin generates default methods in
the new trait encoding.
Unfortunately we can't do this for specialized functions as things
stand: specialization leaves the wrong method abstract. In principle,
we could/should amend the specialization transform to fix this. But
my earlier attempts at this weren't sucessful, so for now we have
to stick with the fallback plan of keeping some hand rolled functional
interfaces around.
This commit reduces the surface area of
scala.runtime.java8tothe minimal requiremnt: one functional interface for each specialized
variant of
Function{0,1,2}.Fixes scala/scala-dev#121