[erlang-questions] Why we need a -module() attribute?
Joe Armstrong
erlang@REDACTED
Thu Feb 18 12:55:18 CET 2016
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
More information about the erlang-questions
mailing list