[erlang-questions] Current state of packaged modules: net.rtmp.decoder
Wed May 12 05:52:50 CEST 2010
On May 11, 2010, at 9:53 PM, Max Lapshin wrote:
> Hi, I can't understand why is not recommended now to use packages of
There are several important things here.
(1) Erlang allows dots in atoms, always has. foo.bar.ugh
and @ugh and foo_bar_ugh are just plain atoms.
They are the _same_ atoms as 'foo.bar.ugh', '@ugh',
This does _not_ apply to Java, where foo_bar is one
identifier but foo.bar is not.
(2) Historically, the module system treated all atoms alike.
There was no connection between foo.bar and bar any more
than there was any connection between and bar or
between foo_bar and bar. In the same way, Java sees no
connection between a class called Foo_Bar and a class
One of the fundamental concepts in computer programming
is alpha-conversion (the idea that names are *arbitrary*
labels). It is generally a bad idea to violate this.
(3) Formerly, in -module(fred), a call jill:bucket(56) was a
call to the module 'jill'. Change the -module directive
to -module(demo.fred) and that call now refers to the
module 'demo.jill'. This is fine when you want it to
happen, but if your code referred to existing OTP modules
such as 'lists', well hello demo.lists breakage. You _can_
refer to top level modules using ''.lists or .lists, but
that's an incompatible change.
(4) It's really not clear how all of this works *dynamically*.
Before dotted module names got special treatment,
M = jill, M:bucket(56), %B
apply(jill, bucket, ), %C
'my.module':'my.apply'(jill, bucket, ) %D
were all equivalent, where
my.apply(M, F, A) -> apply(M, F, A).
The abbreviation kluge obviously works for %A. It could
be made to work for %B by using different (slower!) code
like M = jill, (fix_mod(M, 'my.')):bucket(56), where
fix_mod(M, C) -> case has_dots(M)
of true -> M
; false -> atom_append(C, M)
It's easy to make %C work when the first argument is a
constant, like %A, and when the first argument is not a
constant, the same technique used for %B will work.
But how do you make %D work?
(5) There are no actual packages. There are directories where
modules with the same prefix will be sought, but it is not
the case that all files with the same prefix must be in the
same directory. A "package" is nothing but a bunch of modules
with a common prefix to their names; there are no package
(6) Package names are back to front. This has been explained repeatedly
in this mailing list. They are like absolute file names, not like
relative ones. If I need the same package in two places in the
package hierarchy, I can't do it. I can't move a package up or
down in the package hierarchy without surgery on every file. I
cannot make a *component* that my customers can place anywhere
they want in the package hierarchy. And if I can't do *that*,
what the heck is the package system *for*?
- dotted module names was not a new thing
- mapping dotted names to the file system as described in
obviously has its uses, but this could be done with any
character, including @, or indeed by other means entirely
(like Eiffel's LACE)
- the scheme leads to increased work when adopting dotted names
and makes renaming packages difficult and fragile
- it does not seem that dynamic behaviour can match the static
abbreviation facility without increased costs (when known
functions/forms are involved) or at all (when user defined
functions are involved)
> What is bad in
> using dotted names? What is the future of this feature: it will be
> developed or it will be deprecated?
It should be taken out and shot.
*Some* sort of module connection/configuration facility is needed,
but I suggest as a design criterion that it should be possible to
move an entire "flotilla" of modules in the package name space
by changing *ONE* line in some file.
More information about the erlang-questions