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()
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()
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.
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.
the question should not be âwhy?â but rather âwhy not?â Why not support it and let people decide whether to use it or not?
Plenty of reasons, such as:
(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â.)
@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,
@yole Any news? I wrote comment about package scope on 2018. From that time I didnât use kotlin .
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.
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
@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.
@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.
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.
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.
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.
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).