Introduce a binary API with Scala functions in Reflect.
#5161
Conversation
And make its internals independent of JS interop. This way, it will be usable in Wasm without JS host. We use new names for the methods, instead of overloads, because older compilers look for those methods by name only. If an older compiler gets a newer library on the classpath, and the methods with those names became overloaded, the compiler would crash. In this commit, we do not change the compiler yet, to test that the deprecated methods are correct.
6b00b7f to
b223873
Compare
|
I think this is a worthwhile thing to do. Have you given any thought whether we should attempt to make the reflect API Scala agnostic as well? It seems it only relies on Scala only (i.e. non Scala.js IR) concepts superficially. IDK when we first designed this, but it might have been well before the times of the Scala independent javalib. With it, I wonder if we should at least make the interface we design now Scala independent. |
|
We can make the new registration API not use any Scala type. But it won't change the fact that the public API exposes We also need a Java type for the pair of |
|
I've been thinking about this and I'm wondering if it would make more sense to specify registration in terms of IR opcodes. It's essentially functionality provided by the runtime.
But couldn't we make the core implementation rely on Java only and keep the Scala interface an adapter?
Yeah... feels a bit of a stretch after having read the Javadoc, but maybe :-/ |
And make its internals independent of JS interop.
This way, it will be usable in Wasm without JS host.
We use new names for the methods, instead of overloads, because older compilers look for those methods by name only. If an older compiler gets a newer library on the classpath, and the methods with those names became overloaded, the compiler would crash.
In the commit, we do not change the compiler yet, to test that the deprecated methods are correct.
In the second commit, we change the compiler to use the new APIs.
This does not bring any immediate benefit. It's more for a long-term vision. But it also shouldn't hurt, besides the cost of maintaining a deprecated pair of methods. If we had had
NewLambdaall along, I think we would have designed this API using the Scala types to begin with. TheReflectobject never pretended to be Scala-agnostic, since its public API is full of Scala types anyway.