[erlang-questions] Are packaged modules the way to go ?

Thomas Lindgren thomasl_erlang@REDACTED
Thu Jan 8 14:28:59 CET 2009

--- On Thu, 1/8/09, cyril Romain <c.romain@REDACTED> 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
> orthogonal 
> components, with one directory per component and where code
> dependencies 
> 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 mailing list