eclipse-archived
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.
The reason for this warning is that we have to support case-insensitive filesystems. This causes a problem if you have both fooBar and foobar as a package name element.
So why not warn only about actual collisions, as we do for file names?
Well because we don't know all the module names that exist in the universe at compilation time. (OTOH, we do know the names of all source files in a package at compilation time.)
Ah, I was thinking more about package names, not module names. Personally, for module names I don’t think the probability of name collisions is high enough to justify this warning.
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.
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
