Kotlin wrapper updates + fix Scala 3 OperationRead.run ambiguity#47
Merged
Conversation
Why: typr's RC6 migration depends on these — without them the generated Kotlin code can't call into the wrappers, and Scala 3 can't disambiguate the OperationRead.run overloads. - foundationskt.Bijection: add public companion `of(forward, backward)` so codegen can emit `Bijection.of(...)` returning the Kotlin wrapper (the chain of `DbType.to(Bijection.of(...))` then types correctly). - foundationskt.Connection: expose `javaConnection` (was internal) so typr-dsl-kotlin can unwrap when delegating to the Java DSL. - foundations.OperationRead: drop the `run(ConnectionRead)` overload inherited via Operation.run(Connection) was ambiguous in Scala 3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ection)
The previous commit's "remove the ambiguous overload" approach broke
generated read repos in typr-3 — read methods take ConnectionRead but
post-removal there was no run(ConnectionRead) sugar to invoke.
The actual issue was Scala 3's overload resolver not applying specificity
across inherited-vs-declared method boundaries: Java and Kotlin always
picked run(Connection) over run(ConnectionRead) for c: Connection
call sites, but Scala 3 reported ambiguous because one overload sat on
Operation and the other on OperationRead.
The fix: keep run(ConnectionRead) AND re-declare the inherited
run(Connection) on OperationRead. Once both overloads are declared at
the same level, Scala 3 applies specificity correctly and picks the
right one. Pure delegation, no semantic change, both languages stay
ergonomic with op.run(c) postfix sugar.
Verified locally: typr-3 testers/pg/{scala/javatypes,java,kotlin} all
compile clean against this foundations build.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
oyvindberg
changed the title
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Three small foundations changes that unblock typr-3's RC6 migration.
Summary
foundationskt.Bijection: add public companionof(forward, backward)so codegen can emitBijection.of(...)returning the Kotlin wrapper.foundationskt.Connection: exposejavaConnection(wasinternal) sotypr-dsl-kotlincan unwrap when delegating to the Java DSL.foundations.OperationRead: keeprun(ConnectionRead)AND re-declare the inheritedrun(Connection)onOperationRead. Java and Kotlin always picked the most-specific overload; Scala 3 reported ambiguous because the two overloads sat at different points in the inheritance chain. Re-declaring the parent's method on the subtype puts both at the same level, and specificity (Connection <: ConnectionRead) then resolves cleanly. Pure delegation, no semantic change.What this doesn't do
The first commit (496785f) attempted the simpler approach of removing
run(ConnectionRead)entirely. That fixed the Scala 3 ambiguity but broke typr-3's generated read repositories, which takeConnectionReadand need the postfix sugar. The follow-up commit (237e7a4) reverses that approach and uses the explicit-override fix instead — read repos can keep callingop.run(c)against eitherConnectionorConnectionRead, and Scala 3 picks the right overload by specificity.Test plan
bleep compile foundations-jdbc foundations-jdbc-hikari foundations-jdbc-spring foundations-jdbc-kotlin foundations-jdbc-scala— green.bleep compile testers/pg/scala/javatypes testers/pg/java testers/pg/kotlin— all green.testers/pg/scala/javatypes/src/scala/adventureworks/public_/users/UsersRepoTest.scala(the original failing case) compiles clean.🤖 Generated with Claude Code