[erlang-questions] Why we need a -module() attribute?

[T Ty]

Would -vsn be enough ? its MD5 and not Sha1 though.

On Thu, Feb 18, 2016 at 5:53 PM, Éric Pailleau <eric.pailleau@REDACTED>
wrote:

> Hi,
> Sha1 sum of source code is probably note the best solution due to the fact
> that same source file on Windows and Linux may differ due to different
> carriage return. Some are using tab and other spaces. And source with
> comments or without would be different in checksum but same Beam file.
> A canonical version of abstract code is probably better for a checksum and
> could be stored in a beam chunk.
>
> Le 18 févr. 2016 6:27 PM, Éric Pailleau <eric.pailleau@REDACTED> a
> écrit :
> >
> > Hi Joe,
> > I was meaning at compile time, from files on disk.
> > Having several modules in same file is dangerous. This could end by
> having two modules with same name in same file or two same module in two
> different files.
> > With one file per module, called the same, it is unlikely to have this
> clash (well I see sometimes subdirectories under src/... Hirk)
> > It was maybe the original goal of this constraint ?
> >
> > At runtime,  I agree with you, hard to know.
> >
> > Le 18 févr. 2016 12:55 PM, Joe Armstrong <erlang@REDACTED> a écrit :
> > >
> > > On Wed, Feb 17, 2016 at 6:44 PM, Éric Pailleau <
> eric.pailleau@REDACTED> wrote:
> > > > Hi,
> > > > Mho,  module name in file should be unique and same than rootname
> file. This avoid any module clash, not globally but in same app.
> > >
> > > I disagree - the "real" module name should be the SHA1 checksum of the
> > > source code - the "user friendly name" should just be an alias to the
> > > SHA1 checksum.
> > >
> > > The development system should hide or reveal this information
> > > depending upon the context.
> > >
> > > When developing you probably want to talk about a module called "foo"
> > > when you ship code or send code over the network you want know
> > > *exactly* what you did.
> > >
> > > The problem with using a module name to identify the code is that the
> content of
> > > the module changes with time and place.
> > >
> > > In a distributed system we can imagine upgrading code for some module
> > > 'foo' bit that foo.erl is *different*on different machine because the
> > > code has not yet arrived.
> > >
> > > Using "just" the module name will and does get you very rapidly into
> > > "version nightmare land".
> > >
> > > Handling versions is much more complicated than you might think - and
> *nobody*
> > > seems to have got it right - (apart from NiX - which might have got
> > > things right,
> > > but I'm not sure yet)
> > >
> > > Cheers
> > >
> > > /Joe
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > BTW, namespace is probably something Erlang should handle in futur.
> This would avoid any module name clash. But anither story.
> > > >
> > > > Le 17 févr. 2016 6:38 PM, derek <denc716@REDACTED> a écrit :
> > > >>
> > > >> that -module(). line sound like redundant, if it can be mismatched,
> > > >> why can't it be omitted?
> > > >> compiler can derive the module name from the filename anyway; Java
> > > >> also made that filename has to match class name, that is a design
> > > >> mistake and unnecessary requirement, to my opinion;
> > > >>
> > > >> or on the other hand, if -module() is proved to be useful, why not
> > > >> just ignore the filename, and always use what's defined in
> -module()?
> > > >> in many modern language design like Go and Elixir, it's allowed to
> > > >> define multiple Class/Module in one file, this will be really
> > > >> flexible:
> > > >>
> > > >> %% file1.erl
> > > >> -module(module1).
> > > >>
> > > >> %% [content of module1]
> > > >>
> > > >> -module(module2).
> > > >>
> > > >> %% [content of module2]
> > > >>
> > > >> -module(module3).
> > > >>
> > > >> ...
> > > >>
> > > >> On Wed, Feb 17, 2016 at 6:26 AM, Joe Armstrong <erlang@REDACTED>
> wrote:
> > > >> > Well suppose you sent the *content* of the file in a message - how
> > > >> > would the receiver
> > > >> > know the name of the module?.
> > > >> >
> > > >> > Actually the module attribute and file name don't have to be the
> same - but
> > > >> > if they are not you'll break the autoloading mechanism. If the
> file name and
> > > >> > module name are different you should know exactly what you're
> doing :-)
> > > >> >
> > > >> > Cheers
> > > >> >
> > > >> > /Joe
> > > >> >
> > > >> > On Wed, Feb 17, 2016 at 10:45 AM, Konstantin Vsochanov <
> kost@REDACTED> wrote:
> > > >> >> Hi!
> > > >> >>
> > > >> >> I’m working with Erlang for two years now and enjoy every day of
> using
> > > >> >> it. However, there are some strange  features I’m wondering
> about. One
> > > >> >> of them -module() attribute.
> > > >> >>
> > > >> >>  The module name is strictly defined by the name of the .erl
> file. You
> > > >> >> can’t change module name with -module() attribute. But the the
> -module()
> > > >> >> attribute is mandatory. Why? Why we need -module() attribute at
> all?
> > > >> >> Maybe we can make -module() optional in next Erlang release? So
> we don’t
> > > >> >> need to repeat file name in first string of every .erl file. Or
> maybe I
> > > >> >> miss something important?
> > > >> >>
> > > >> >> Feedback is appreciated!
> > > >> >>
> > > >> >> - Konstantin Voschanov
> > > >> >> _______________________________________________
> > > >> >> erlang-questions mailing list
> > > >> >> erlang-questions@REDACTED
> > > >> >> http://erlang.org/mailman/listinfo/erlang-questions
> > > >> > _______________________________________________
> > > >> > erlang-questions mailing list
> > > >> > erlang-questions@REDACTED
> > > >> > http://erlang.org/mailman/listinfo/erlang-questions
> > > >> _______________________________________________
> > > >> erlang-questions mailing list
> > > >> erlang-questions@REDACTED
> > > >> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160218/035e98d3/attachment.htm>