kevin.cianfarini
05/26/2022, 10:01 PMCloseable
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.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.ktStylianos Gakis
06/08/2022, 6:39 AM