Hello, does anyone know why Kotlin kept the conven...

# announcements

[louiscad]

Hello, does anyone know why Kotlin kept the convention of alllowercasepackagenames from Java? What was the rationale? I'm about to name a package in camelCase because it's much more readable that way, but I'm wondering why I should follow that specific convention.

EDIT: Same question for underscores (_) in package names.

[pavi2410]

Package names corresponds to directories they are put in. So, depending on OS, character case of the directory name may cause problems. I am just speculating.

[louiscad]

This was kinda true in the 90s. We're 30 years later, with a language that only compiles on select OSes that don't really have an issue with this AFAIK.

[Ben]

Isn't it more built into the build systems (specifically maven)?

[pavi2410]

Windows filesystem is still case insensitive

[louiscad]

What would be built into them? I'm talking about package names, not about artifact names BTW.

[louiscad]

Yes, NTFS from Windows is case insentive, but that doesn't prevent anyone from naming their files with PascalCase.pas and some directories as well, like Desktop. So why would there be such a lowercaseonly convention just for packages?

[Patrick Lannigan]

Kotlin has a number of pragmatic design decisions that make migrating from and inter-opting with Java code easier. I see this as being one of those cases.

[louiscad]

That specific thing wouldn't prevent interoperability with Java AFAIK.

[Patrick Lannigan]

but it also doesn't significant benefits

[Patrick Lannigan]

I wouldn't consider a small improvement to readability a significant benefit

[louiscad]

Your message 2 times up has a syntax error. Are you missing a word?

[Patrick Lannigan]

I'm saying that changing the naming convention for packages doesn't provide a significant benefit over following the java convention. So based on that, why make the change?
It would make importing kotlin code in java files look different.

[louiscad]

I disagree on the readability part. To me, it makes naming some things harder than it should. I agree with keeping it one word when possible, but for two words, I find concatenating without cameCase or snake_case is counterproductive.

[christophsturm]

package naming in java comes from dns names

[christophsturm]

but you’re free to use camel case if you like.

[christophsturm]

i think camel case looks weird in packages but - should definately be allowed

[louiscad]

About allowing -, maybe you have the quite obvious use case for #C0B9K7EP2?

[Casey Brooks]

Personally, I find that associating packages to domains itself seems antiquated. A lot of projects (especially small libraries/applications and OSS projects) are not associated with any website, so trying to come up with some meaningful domain doesn’t make sense. Projects end up tying their package to Github because of the availability of GitHub Pages domains, or use domains that they don’t own or that don’t even exist. And then if that webpage ever changes its domain…

I’m taking to using a single-level root package, which is just the name of the project itself. Short, simple, and doesn’t try to imply anything about its website

[christophsturm]

i think in kotlin and scala projects the single package = project name pattern is quite common.

[christophsturm]

one upside about the java package names is that they force you to come up with simple names and maybe even more package separation. user.notification instead of user-notification

[adk]

When I see a package called user.notification, I know it is a package and not a class called Notification in a package called user.

[adk]

Personally, I prefer this. In the end, I suspect that it just comes down to personal preference. They had to choose something and one choice will likely have as many detractors as any other.

[adk]

It's the sort of thing that I would choose using rock-paper-scissors

[louiscad]

user_notification and user-notification are not class name candidates as per naming convention

[Matteo Mirk]

I’d like to add that in Kotlin a file’s location and package declaration don’t have to match, as it was in Java. For example you can have a file located at src/my-file.kt having a declaration package foo.bar.baz.
Package declarations can include underscores or be camel case, I don’t know of any conventions on the matter, but hyphens are not allowed by the compiler.

Also, there is one convention in Kotlin that helps you simplify directory structure (if you want to follow it) that you can start your source tree root eliminating your common package prefix, that is if your packages are like:

x.y.z.model
x.y.z.service
x.y.z.util
...

your source tree should be like:

src/
 ├ model/
 ├ service/
 └ util/

https://kotlinlang.org/docs/reference/coding-conventions.html#directory-structure

[gildor]

A lot of projects (especially small libraries/applications and OSS projects) are not associated with any website, so trying to come up with some meaningful domain doesn’t make sense

It makes a lot of sense for artifact group, it’s the only way to proof that some library belongs to the same domain. It also common practice to use packages like com.github.myproject, it also supported by github pages

But should artifact group be the same as package? not necessary, but it’s often quite useful to have consistent name