<https://youtrack.jetbrains.com/issue/KT-29227>

# announcements

[ghedeon]

https://youtrack.jetbrains.com/issue/KT-29227

[Marc Knaup]

It's prefer to get rid of packages entirely and only rely on modules. Works beautifully with Swift and I don't see why it shouldn't for Kotlin.

We may need a bit better support for nesting. The ToolbarState in your example you could simply nest in the respective screen or view model.

Do you have any concrete examples for variables and methods which should be package private?

[ghedeon]

how is modules a replacement for packages? What stops you now from having 200 gradle modules? Maybe.. idk.. sanity?

[ghedeon]

Nesting helps with imports but doesn't help with visibility: you still see classes that you don't want to see.

[ghedeon]

any component, that exposes simple interface, but has a non trivial implementation has a set of internal helpers that should never be exposed to the external world. And if the said component is big enough — one file is not an option.

[Marc Knaup]

What kind of project needs 200 packages?
Overuse of packages is a relict from Java which I think is unnecessary for any project and usually the result of over-architecturing.
I have projects from small to large and usually one package per module is more than fine. If it grows beyond a certain size then there should be an architectural cleanup by breaking it into multiple modules. But still that wouldn't end up anywhere near 200.
And when you get to enterprise-size projects with hundreds of developers then 200 modules is absolutely fine.

[Marc Knaup]

If a single component would become too bloated in a single file then it's functionality should also be broken down using composition.
Any time there is "too much at once" it is a signal that there is an architectural problem which can usually be solved by improved abstraction.

[Marc Knaup]

Do you have any concrete example as a good basis for further discussion?

[ghedeon]

Honestly, I don't understand this switch off roles here. The burden of proof is on JB here. They changed something that was working fine without giving a convincing reasoning, beside that "it's not secure".

[ghedeon]

Yes, ToolbarState is a good example.

[Marc Knaup]

That's not an example, that's just a name of a type.
I mean an extensive example with multiple files and classes where the problem you outline becomes obvious.

[ghedeon]

It's not part of the ViewModel's or View's interface, so nobody from the outside of these 2 classes cares about ToolbarState. Yet, I'm forced to bump on it in my whole presentation module.

[ghedeon]

it's very obvious when you use MVI and have the same states and events on every screen.

[Marc Knaup]

still, discussing it based on real code rather than a hypothetical scenario (you haven't shared any code yet) would make this discussion much more useful

[ghedeon]

We have to agree to disagree here. Multiple complains on SO and kotlin forum is enough for me to believe that it's a valid case for a lot of people. So, just let the community to do it's job, you don't have to convince me.

[ghedeon]

I just noticed that you wrote "one package per module is fine". For a hackathon? hello world app or utility module? In 7 years I didn't see a single decent project with one package. Why would you present something that unrealistic as a good practice? Where this dogmatism comes from, I don't understand. Was there any related talk from Uncle Bob or another "guru" that I missed?...

[Marc Knaup]

I've developed apps and back-ends for 10 years and even large apps and back-ends were totally fine with 20-40 properly separated modules having just one package each.
One package doesn't mean one module - each project needs to find the right balance between being able to access too much and too little. Using modules also forces a strong focus on proper abstraction, esp. if you don't want too many of them.

In Swift for example there are no packages, only modules, and even large app codebases can do totally fine without having the feeling of missing something. It's just that Java developers got so used to think in packages. I love that Kotlin deliberately breaks that and simplifies language and architecture, esp. with multi-platform development in mind.