John Meacham wrote:
Package names should never appear in source files IMHO. if a package name is in the source file, then you might as well make it part of the module name. packages exist for 'meta-organization' of code. A way to deal with mapping code _outside_ of the language itself, putting packages inside the code will force the creation of yet another level, meta-packages, or something. packages should not be a language issue, they are an environment one.
Indeed, that's the principle we've been following with the package design up until now. There are (were) two principles: 1. packages should stay out of the language 2. module names should reflect functionality *only* Sticking to these principles rigidly has left us with a problem, namely that packages lack proper abstraction properties. A hidden module in a package is visible externally, because all packages share the module namespace. So how do we fix that? a. we could put package names in module names as you suggest. But apart from sacrificing the second principle, this doesn't let you import a module from a package without specifying the exact version of the package ==> BAD. b. we could add compiler options that let you graft the module namespace of a package into the global module namespace at an arbitrary location. c. instead of grafting, we add language support to allow importing modules from a particular package (crucically, you don't have to specify the version). We were thinking about (b), when people started suggesting (c). Although (c) breaks the first principle, in many ways it's rather nicer than (b). I don't think (a) is a goer at all. So that's where we are now, if you have a better idea then let's hear it! Cheers, Simon