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

[Robert Virding]

I quite agree with all Richards comments/critiques and would like to
add one more:

(7) It imposes a directory structure on packages which I think is
undesirable. I do not want the language to force me to structure my
apps in a special way. Currently all that OTP assumes is that the
source code for a module is in a file called <module name>.erl and the
BEAM code is in a file called <module name>.beam. This, I think, is
quite enough. It is actually not too difficult to get around the
second one if you are prepared to load code yourself.

Otherwise I can add '_' in my module names myself.

-1

Robert

On 12 May 2010 05:52, Richard O'Keefe <ok@REDACTED> wrote:
>
> 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.
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>