Kotlin to support package protected visibility


#41

From what I can see, the main problem with internal compare to package private is that internal is tied to Gradle/Maven modules. This discourages developers from building small modules, as doing so affects compilation time and complexity of the overall project structure. Package private solves those problems, but introduces a lot of problems by itself. Instead, I propose that we look for alternative solutions. My suggestion would be to add a notion of modules within the language itself, that are more lightweight than what the build systems offer, but also more flexible than packages, since packages are restricted to a single namespace and a single directory file structure.


#42

The “lightweight” module I prefer is the ability to mark a package as a module. This restriction is only enforced at compile time. Those members marked with internal will then be compiled to package-private members post-fixed with ugly module name to tell Kotlin it’s internal.