https://kotlinlang.org logo
Title
p

Patrick Steiger

05/21/2023, 4:00 PM
Not sure the right channel to ask this — in many Kotlin libraries we often see an
internal
subpackage. What is it for? I mean, isn’t putting internal visibility stuff in the root package the same? E.g
kotlinx.coroutines.flow
kotlinx.coroutines.flow.internal
What problem does this solve?
m

mkrussel

05/21/2023, 4:11 PM
I don't know about coroutines specifically, but sometimes people put things with a public visibility in an internal package because it needs to be public for other modules of the library group but not public to consumers of the library group. This would normally also be followed with an opt in annotation. I've also done this do to expect/actual requiring something to be public, because the actual is a typedef to a public class. The other possibility is create something like a package-private, which Kotlin doesn't have. So the thought would be only code in
flow
or
flow.internal
should access code in
flow.internal
. It would be easy to create a static checker to enforce something like that.
e

elizarov

05/22/2023, 7:42 AM
Yes to the above. This is a standard pattern for big libraries (big as in “consisting of multiple packages”). On JVM (without JPMS) you cannot really forbid 3rd parties from using your “module-private” parts (since they are all have to be public), so naming the corresponding package
internal
(sometimes
impl
is also used) hints that those are not supposed to be used outside. With JPMS you can enforce it, but it also requires you putting all those declarations into a separate package (that you will not export from your library)