[erlang-questions] Are packaged modules the way to go ?
Thu Jan 8 14:28:59 CET 2009
--- On Thu, 1/8/09, cyril Romain <> wrote:
> A project without packaged modules:
> - has a flat module structure (i.e. there are no modules
> within modules).
> - generally has, if not always, its sources files (*.erl)
> in one
> directory with no subdirectory. Same things for binary
> files (*.beam).
Not really. A project (aka 'release' in OTP) would normally consist of many 'applications', each of which has its own directory tree with src/ and ebin/ subdirectories (among others).
> - tends to use the following name convention to avoid
> file/module name
> clashes: myapplication_mycomponent_mymodule.erl (sometimes
> there is no
> mycomponent, and more rarely no myapplication in the name).
> Abbreviations such as myapp instead of myapplication are
> often use to
> avoid very long name.
Naming in practice tends to use app_mod, not app_comp_mod. In some cases, particularly core libraries, the name is just mod.
> Packages modules suggest to the developers to split their
> software into
> sub-component, which is good IMHO. Project containing ton
> of source
> files are indeed easier to work with when split into
> components, with one directory per component and where code
> are more clear.
Such packaging is usually done at the application level, and if you so wish, an OTP application can be seen as a component. For instance, the application need not start a server; just provide a collection of modules. I seem to recall this is called a 'code application'. Applications can then require each other, etc etc.
(An aside for those who want packages: should applications also have a hierarchical name space? While applications are not a part of the language, I suppose we will run into the same problems?)
Personally, I think the idea of a non-flat module name space is attractive, but packages as proposed are not quite what is needed. (Even if I ignore at least one killer bug.)
More information about the erlang-questions