Kotlin to support package protected visibility

I would also like to have this feature, preferably the way Scala does it, where you can decide how far down you want to expose stuff:

package foo.bar.baz

private[bar] fun test()
2 Likes

Extending stuff just to achieve this is counterproductive… having multiple implementations of an interface, or subclasses hits you at runtime, but that was interesting regardless.

I’ve given up on it, at this point i’ve made peace with the fact that i will have giant kotlin files with tons of stuff in them or i will have too open classes that are not supposed to be exposed.

Because its not that pressing issue they will keep delaying or thinking its a non issue. Even from responses of the language devs its pretty evident they didnt think this is a problem at all…

Who cares that i have 15 classes in one file. This is not an issue that community can just do on the open source style… it needs IDE to recognise visibility changes etc…

yes its neat, its intuitive and covers all the important cases

yes its neat, its intuitive and covers all the important cases

C’mon guys, we still don’t have the package visibility?

So in your mind packages are not a way of modularizing?

I hope you have grown in experience since this comment of yours from 2016 and are now able to see different abstraction layers into modularization.

Whoa, 8 years flew by.
In the meantime I did find package visibility necessary for modularization.

1 Like

Anyone outside jetbrains have experience with kotlins compiler implementation? how hard would it actually be to add support for package visibility… since it compiles to java compatible bytecode i think there would be nothing stopping us from forking and just adding it in… i’m guessing just kotlinc IR needs to know about the new visibility and fail compilation when something tries to wrongly access inaccessible class at compile time…

We could straight up not change anything in actuall compilation just add failure when its package visiblity violated but treat it as public… i mostly care that i could use a package visibility working with source and prevent people from creating uber.kt fies or making everything public.

What would be the benefit of this? I mean, package-private doesn’t really provide anything new, does it?

IDE would still show all package-private symbols as public or it will show syntax errors, until you modify the IDE plugin as well. If you use any other tools for Kotlin, they may need forking as well. Then you need to instruct all your developers that your company doesn’t use the standard Kotlin language, but its custom fork. You need to install all these additional tools for custom Kotlin into all developer machines. It may be problematic to consume your library by a project using a standard Kotlin compiler (although not necessarily). Is it really worth the effort to just hide something?

well it will provide all benefits of the package visibility as in java, you will not be able to use classes if you violate the visibility… the idea uses the compiler and will give you the ssame error you get in java…

I’m not sure how tricky it is to use the custom version, but rebasing on latest kotlinc will be trivial, + it will give us some idea how such things can be added + a chance that jetbrains will merge it or make a better version?

for now i will use it for my personal use and in my team.

Regarding compiling as if package = public, its just in case there are some hidden reasons they are not implementing this… maybr something breaks or whatever. I dont plan to do it, but if there are some issues thats an option, it is irrelevant if its actually public in bytecode, all we really need is to not let people do uber.kt or everything public antipattern…