Packages in Erlang: new documentation

Chris Pressey <>
Thu Sep 4 18:55:16 CEST 2003


On Wed, 3 Sep 2003 14:34:49 +0200 (MET DST)
Richard Carlsson <> wrote:

> Since the R9B release of Erlang, "packages" (hierarchical module
> namespaces) have been available for testing by the Erlang community.
> 
> It seems that the information about this, and how it works, has not
> reached enough people. I have therefore written a new piece of
> documentation about packages in Erlang, in the hope that it will
> be better understood, and more people will try it out:
> 
>     http://www.csd.uu.se/projects/hipe/packages.html
> 
> In particular, see the section about migrating code into packages.
> 
> All comments appreciated,
> 
> 	/Richard

Well, I was doing a overhaul of OpenFlax anyway, so I decided to
packagize it to see what it's like.

It used to look like:

openflax-xxxx.yyyy/src/openflax.erl
openflax-xxxx.yyyy/src/openflax_log.erl
openflax-xxxx.yyyy/src/openflax_http.erl
openflax-xxxx.yyyy/src/openflax_http_request.erl
openflax-xxxx.yyyy/src/openflax_http_response.erl
(etc, and)
openflax_mod-xxxx.yyyy/src/openflax_mod_file.erl
openflax_mod-xxxx.yyyy/src/openflax_mod_upload.erl
(etc)

Now it looks like:

openflax-xxxx.yyyy/src/openflax/app.erl
openflax-xxxx.yyyy/src/openflax/log.erl
openflax-xxxx.yyyy/src/openflax/http/middleman.erl
openflax-xxxx.yyyy/src/openflax/http/request.erl
openflax-xxxx.yyyy/src/openflax/http/response.erl
(etc, and)
openflax_mod-xxxx.yyyy/src/openflax/mod/file.erl
openflax_mod-xxxx.yyyy/src/openflax/mod/upload.erl
(etc)

...with a similar tree under ebin/ (i.e. I don't prefer to put source,
object, and doc files all in the same directory, I think it's messy.)
The deep directory structure caused some frustration with my build
scripts (which were of course originally hacked up to expect a nice flat
workspace,) but nothing insurmountable.

All in all it's not as bad as I feared.  My experience is similar to
Ulf's in many respects.  I left most of the references fully qualified
(e.g. I just changed openflax_log:write to openflax.log:write rather
than shortening it to log.write.)  Intuitively I expected to be able to
import not just a module but an entire package (e.g. to say
-import(openflax.http) and then say http.request:collect) but it looks
like that's not supported.  In this sense, and in some that Richard O.
mentioned, it just doesn't "feel" very hierarchical.

The combination of flat code path and package hierarchy is...
interesting.  Probably too complex as it stands, but also it's kind of
convenient (for me) that the openflax_mod application can stick modules
in openflax's packagespace, just like without the hierarchy.  If the
code path were eliminated, things would get trickier (since I do want
these to be seperate applications - openflax is the base which is
minimal and tight, and openflax_mod is the set of addons which is
featureful and necessarily somewhat less tight.)

I also wonder about some stylistic issues.  'openflax' was effectively
renamed 'openflax.app' - I could have chosen 'openflax.main' or
something else, or just left it 'openflax', but I didn't know how having
a module name the same as a package name would have affected things.

I'm not sure if the mapping of module names to file names is a hard
problem, or just a messy one.  It might be nice to have some specific
rules in that regard (e.g. module names must be lower-case alphanumeric
plus underscores and be no more than X characters long.)  In the worst
case, this would make it easier to construct name-mangling algorithms
for filesystems which have different rules.

Oh yeah, one last thing: it would be really nice if
  io:fwrite("~p", [dotted.atom])
wouldn't add the unnecessary single quotes.  But that's not a big deal.
All in all it was nicer than I expected; I can live with it until
something even better comes along.

Just my 2c
-Chris



More information about the erlang-questions mailing list