[erlang-questions] Current state of packaged modules: net.rtmp.decoder

[Richard O'Keefe]

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
> modules.

There are several important things here.

(1) Erlang allows dots in atoms, always has.  foo.bar.ugh
     and foo@REDACTED@ugh and foo_bar_ugh are just plain atoms.
     They are the _same_ atoms as 'foo.bar.ugh', 'foo@REDACTED@ugh',
     and 'foo_bar_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 foo@REDACTED 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
     called Bar.

     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,
	jill:bucket(56),				%A
	M = jill, M:bucket(56),				%B
	apply(jill, bucket, [56]),			%C
	'my.module':'my.apply'(jill, bucket, [56])	%D
     were all equivalent, where
	-module('my.module').
	-export(['my.apply'/3]).
	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)
			 end.
     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
     properties.

(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*?

So:
   - dotted module names was not a new thing
   - mapping dotted names to the file system as described in
     http://www.erlang.se/publications/packages.html
     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.