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

[Nicholas Frechette]

I agree with 7 not being ideal. From memory Java imposes something similar
with packages and I never liked it. However, I could live with it.
Also, erlang already imposes a directory structure in other features:
for code:lib_dir to work, your beam files (or is it app file?) must be in a
directory structure resembling: /.../app-version/ebin
If this is not the case, -include_lib("app/include/foo.hrl"). will not work
as code:lib_dir fails to find the app package directory. I recently ran into
this myself and cursed/cussed quite a bit.

Seeing as the evil is already within, it doesn't sound half as bad to let it
stay and spread to packages.

On Wed, May 12, 2010 at 6:40 PM, Robert Virding <rvirding@REDACTED> wrote:

> 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
> >
> >
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>