By the way I start warming up with a question: Any...

# language-evolution

[Pablichjenkov]

By the way I start warming up with a question:
Any progress in private package or bringing Friend classes to the language?
I feel like internal does not fill all my needs.

[Mike]

I wouldn't expect package private, especially given how easy it is to bypass it anyway, and create more trouble than it's worth.

If it's to prevent usage within a given module, i.e. trying to ensure things in the service package don't talk to the database items, or something, then perhaps database should be its own module?

And I suspect that's the viewpoint the Kotlin maintainers are taking.

Generally speaking, the Kotlin devs are trying to keep the language as simple as possible, and avoiding edge cases as much as possible.

But that's just my take on them.

[Pablichjenkov]

There is a long thread on JetBrains issue report portal discussing about this. Benefits vs Disadvantages.
It looks like JB accepted to take on it but nothing has been released.
The module approach works to protect modules from each other. However, sometimes you want to protect classes usage even in its own module. It makes API design cleaner and prevent maintainers using a class where they should not be using it.
I see package private as a way not to fully protect Class usage but to indicate another code maintainer about the scope of the class.
But well seems like JB is not happy about that.
The other approach which is Friend classes seems like has a lot of not likers in C++.
But again internal and private to file classes still missing something IMHO.

[Mike]

I think the big issue with package private is the fact that any consumer of the library can override those merely by placing their mods in the same package, even if it doesn't 'belong' in their package. We've all done it, and then complained when the maintainer decides that package or implementation or something shouldn't be touched.

No right answer here, but I can see issues either way. Agree that something is missing, but also agree that package private, nor internal fully covers the cases. Almost need an internal package-private so can only be used in the module AND can only be used in the package...

[Mike]

So perhaps that's the suggestion. That package-private (or whatever name is decided) is both package private, but also internal. Solves my concern, and I think yours as well.

[Pablichjenkov]

It has good potential, yes.