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()
3 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.

2 Likes

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


I read the entire discussion, and I think everyone has their own valid arguments. However, I believe the question should not be “why?” but rather “why not?” Why not support it and let people decide whether to use it or not?

From much of the discussion here (except for a few points that I don’t agree with), what is needed is a combination of package-private and internal visibility to keep the code inaccessible from outside the module and from non-friends within the same module. I can’t think of any reason this could hurt anyone, but there are people here who say they are actually being hurt right now.

I am not sure about the statistics, but I am quite sure that most Kotlin developers are current or former Java developers, and they are familiar with the way Java encourages package design. If they were mostly C# developers, I would understand that “internal” would be the best choice, but that is just not the case.

Package-private visibility is mostly not about testing. Its benefits in terms of testing are just a side effect that unfortunately became a common convention, but in my opinion, that is completely irrelevant to this discussion.

If Kotlin’s main community is comprised of Java developers, then I think it should honor their habits as long as those habits are shared by a large part of the community and are not undeniably bad programming practices. Hiding classes from each other via packages is an encouraged way of code design in the Java ecosystem. It is not a “good” or “bad” practice; it is just a practice that has been encouraged and a very large community of developers is used to. Java could have been designed differently, and that would not be the case, but we can’t change history.

I hope the Kotlin team listens to the actual people who contribute to Kotlin’s growth and gives them what they need instead of turning this into a programming ideology discussion.

1 Like

Plenty of reasons, such as:

  • Everyone will need to learn it — not necessarily so they can use it themselves, but so that they can understand everyone else’s code, use libraries, etc.
  • Writers of compilers, IDEs, plugins, and other tools will need to update all their software to handle it.
  • Every extra feature increases the complexity of the language and makes it that little bit harder to learn and use.
  • Once added, it’s almost impossible to remove.

(That’s just OTTOMH; there are probably many more.) So a language feature must bring a significant benefit if it’s to outweigh all that.

But don’t take my word for it — this is a well-known issue in language design, and has become known as the ‘minus 100 points rule’: the idea that when rating prospective language features, each one starts out with a deficit of 100 points, so that you need to demonstrate some very clear advantages before it attains a positive score and becomes worth considering.

So no, “Why not?” isn’t a very strong argument, I’m afraid. The onus is on you to show that it’s worth adding — enough to justify the disadvantages above.

(And IMO one of the reasons that Kotlin is such a good language is that the designers had great taste in deciding not only what to put in, but also what to leave out. Removing, simplifying, or abstracting over many Java features is what enabled them to add great new features within a broadly similar ‘complexity budget’.)

1 Like

@gidds Thanks for sharing those details I wasn’t aware of. That post you shared was quite interesting but in the end, I guess most of us here are not language designers. We have a real world frustration and a big pain in terms of Java interoperability.

Regarding your concerns,

  1. Everyone doesn’t have to learn it, only the ones who really need it. Just like “inline” or “reified” or the “OptIn”. All languages have features that only a small fraction of the community know in detail.
  2. IMO, the reason that writers of all supporting tools have to update their software cannot be an argument as long as it is extremely hard to implement. That’s what they do and they will have to change their software for the other features coming with the next release anyway. If this is one of those extremely difficult tasks, then let JetBrains tell us that and we’d have no choice to live with it.
  3. I don’t see any reason why one would want to remove such a feature but if such a need arises, its affect on the developer is much less compared to removing other language features like for instance the “extension functions”. Let’s say it is removed, then it could be replaced with “public” as other modules might have relied on the exposed package protected code (which would probably be very rare) and the library author can then deprecate the code and gradually convert to “internal”. In the end, package protected code is already “conceptually internal” and people know that they shouldn’t depend on it from other modules. If they do so, it is mostly intentional. Again, I don’t foresee such a need but if you do so, please share and let all of us discuss and learn
1 Like

@yole Any news? I wrote comment about package scope on 2018. From that time I didn’t use kotlin :frowning: .
There are 2-3 reasons why Kotlin cannot bring Java users or grow its user base. I even think that it would disappear like scala if not “IntelliJ” that is used for Java development.

  1. no package scope and ignoring java community, that would like to move to Kotlin, but yeah 
 apparently Kotlin don’t want to be popular.
  2. Scala and Kotlin allows amazing over-packed one liners - that takes too much brain power to read it and understand it.
fun maxFigure(a: Int, b: Int, c: Int): Int = if (a > b) a else if (a < b) if (a > c) a else b else b
  1. NO one way, but too many ways for doing stuff.

@gidds
3. removing package scope would super easy by just making package_scope modifier as an alias for public

I would say there is only one main reason: tech “conservatism” of IT companies. I never heard any engineer saying they would like to jump to Kotlin, but they hold due to missing features or something. Engineers are always enthusiastic to try new things, but this is not always good for companies due to increased complexity, maintenance, additional required skills for employees and a risk associated with introducing an entirely new technology.

1 Like

@broot well maybe they won’t say that, because it would be too perfect. But the problem is there. In this case we know the feature that we all here missing and still we don’t receive it. it is stupid.

I think usually devs have small project to test Kotlin but eventually they get back to java again. Definitely Kotlin has a problem.

It just sad that 6 years later nothing have changed with “crucial” java feature.

  1. Missing package scope as a reason not to use Kotlin? No better reason really? I have switched to Kotlin and would never come back to Java voluntarily; and while I might sometimes use package scope, I can’t think of time where I actually needed it. Probably never. I do not really care about packages. If I want to hide something from another code, I use either encapsulation or modules.

  2. Saying that Kotlin ignores the Java community because of missing package scope is like saying that the car industry in 1900’s ignored the horse riding community, because the cars did not need horse shoes.

  3. over-packed one liners - well, if you write bad code, that’s not the problem of the language. The syntax is there for other purposes than to write like a pig. Yes, I have seen a lot of code like that. The difference with Kotlin vs. Java is that with Java you need to write tons of boilerplate, while in Kotlin you can skip that. It is up to the developer not to write unreadable code. That is not Kotlin specific.

  4. If you did not use Kotlin since 2018, then you are arguably unaware of how to use it properly and how a good project in Kotlin looks like. My company has around 2 million lines of code in Kotlin; in Java, I estimate that would easily be 6 million. Facebook has over 10 million lines of Kotlin (I could find the source if you need).

2 Likes