Regarding `Kotlin extension functions` VS `future ...
# getting-started
e
Regarding
Kotlin extension functions
VS
future Java class instance methods
. Name collisions
I’ve been thinking about name collisions between extension methods and future instance methods and the potential for silent behavior changes. Example:
Copy code
// The code:
fun InputStream.bufferedReader(): BufferedReader = ...

// Usage:
val reader = socket.getInputStream().bufferedReader()
(Imaginary situation) Later, suppose in JDK Java
bufferedReader()
instance method will be added to
InputStream.java
itself:
Copy code
public BufferedReader bufferedReader() { ... }
When we increment Java version in our project, on recompilation: • Calling
bufferedReader()
now uses the new Java instance method instead of my extension method. • For my extension method there will be compiler warning only like:
This extension is shadowed by a member: 'fun bufferedReader(): BufferedReader' defined in 'java/io/InputStream'.
This seems like a foot gun and bug that can easily slip through when the project codebase gets upgraded to a new Java version. Having pipeline-style with pipe operator function calls in Kotlin itself (e.g.,
stream |> bufferedReader
) like in Elixir/Gleam languages would avoid that because we would use pipe operator
stream |> bufferedReader
to mimic extension methods, so there won't be name collisions. That is we would use
stream.bufferedReader()
for instance methods AND
stream |> bufferedReader
to mimic extension functions. Giving today's state of Kotlin : • How do you handle this risk in your Kotlin codebases? • Is there a way to have the compiler error on these collisions?
h
This only happens when you recompile your own code with updated dependencies/sdk and you need to always check the new behavior 🤷🏻‍♂️
👍 2
And you can enable warnings as error to fail your build.
👍 2
h