https://kotlinlang.org logo
k

kevin.cianfarini

05/26/2022, 10:01 PM
I'd like to re-raise
Closeable
as a feature Kotlin developers desire in the common stdlib. Here's an associated YouTrack Issue. This conversation has been brought up several times, and the argument against
Closeable
being defined in common was that the stdlib doesn't use it anywhere. Library maintainers have coped by creating their own implementations of
Closeable
and
use
. This is undesirable because: 1. Consumers of these libraries have to rectify multiple different namespaces of what is essentially the same interface. 2. Library maintainers need to recreate closeable for every one of their projects. Right now, Okio, SQLDelight, and Ktor all have their own implementations of
Closeable
. I'm sure there's many more libraries which do the same. I personally feel that coalescing around a single implementation of
Closeable
is import in the Kotlin ecosystem now that we've shown it to be a common use case in multiplatform code.
👏🏼 1
👏 15
Furthermore, libraries are starting to depend on other library implementations of
Closeable
. For example, Zipline by CashApp leans on
okio.Closeable
. https://github.com/cashapp/zipline/blob/c67a4b18f597bdffa9c50351ef04bcd1a48f8f0f/z[…]tecode/src/main/kotlin/app/cash/zipline/bytecode/lineNumbers.kt
s

Stylianos Gakis

06/08/2022, 6:39 AM
apollo-kotlin also seems to have implemented their own implementation of closeable initially. But due to them depending on okio already anyway, this was changed to use okio’s alternative just 9 days ago on an unreleased version of the library as of right now. Just thought I’d add another example that is also multiplatform 🤗
👍 1
2 Views