package/module name recommendation is too heavy-handed

The compiler currently produces four warnings in ceylon.ast.samples, about the package names ceylon.ast.samples.turingMachine, ….bodyReturnRewrite, ….completeCompilationUnit, and ….removeExtraInfoVisitor:

warning: all-lowercase ASCII package names are recommended

I also have some subpackages triggering this warning in other projects.

Since the compiler’s policy bans both camelCase and snake_case, I see no option left to “correct” those package names, other than making them unreadable (bodyreturnrewrite). As such, I think this restriction is much too heavy-handed. I also don’t understand the rationale for it – if, as @jvasileff says, it’s just taken from Java, where it’s apparently supposed to prevent conflicts with class/interface names¹, then I think it makes no sense at all in Ceylon, which also features (lowercase) toplevel functions and objects.

¹ John also argues that this policy doesn’t make sense in Java either, since the initial case should be enough to distinguish between a Class and a package.

[zamfofex]

By the way, it’s interesting to note that Oracle’s Java tutorial says that, when converting a domain to a package name, hyphens should be converted to underscores.

Additionally, Google’s style guides for Java say that multiple words should simply be concatenated without underscores or different casing.

I myself would really hate to see camel case being used for packages/modules. Not only for the reasons @gavinking mentioned, but also because I’m really not used to seeing uppercase letters in package identifiers. Although I know it’s subjective, I just think that it feels off.

Additionally, I generally prefer underscores over camel‐case; if I could choose a convention for a language, I’d definitely choose underscores.

My list for naming package segments is, in order of preference is:

• snake_case_for_the_win
• nocasewhatsoever
• camelCaseKindaSucks

[jvasileff]

I agree with @lucaswerkmeister that this won’t happen often. I also think that it is the responsibility of the organization owning the namespace to avoid naming conflicts and illegal nesting.

OTOH, Herd and the CLI tools should have errors (maybe they do already?) for attempting to store modules that conflict with existing modules in a way that is incompatible with the repository storage layout. Warnings aren’t sufficient.

Related, it looks like there is a repository conflict for the modules simple.v/simple-v.car and simple/v, with both having a filesystem entry modules/simple/v/simple-v.car.