<div dir="ltr">Would -vsn be enough ? its MD5 and not Sha1 though.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 5:53 PM, Éric Pailleau <span dir="ltr"><<a href="mailto:eric.pailleau@wanadoo.fr" target="_blank">eric.pailleau@wanadoo.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
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.<br>
A canonical version of abstract code is probably better for a checksum and could be stored in a beam chunk.<br>
<div class="HOEnZb"><div class="h5"><br>
Le 18 févr. 2016 6:27 PM, Éric Pailleau <<a href="mailto:eric.pailleau@wanadoo.fr">eric.pailleau@wanadoo.fr</a>> a écrit :<br>
><br>
> Hi Joe,<br>
> I was meaning at compile time, from files on disk.<br>
> 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.<br>
> With one file per module, called the same, it is unlikely to have this clash (well I see sometimes subdirectories under src/... Hirk)<br>
> It was maybe the original goal of this constraint ?<br>
><br>
> At runtime,  I agree with you, hard to know.<br>
><br>
> Le 18 févr. 2016 12:55 PM, Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> a écrit :<br>
> ><br>
> > On Wed, Feb 17, 2016 at 6:44 PM, Éric Pailleau <<a href="mailto:eric.pailleau@wanadoo.fr">eric.pailleau@wanadoo.fr</a>> wrote:<br>
> > > Hi,<br>
> > > Mho,  module name in file should be unique and same than rootname file. This avoid any module clash, not globally but in same app.<br>
> ><br>
> > I disagree - the "real" module name should be the SHA1 checksum of the<br>
> > source code - the "user friendly name" should just be an alias to the<br>
> > SHA1 checksum.<br>
> ><br>
> > The development system should hide or reveal this information<br>
> > depending upon the context.<br>
> ><br>
> > When developing you probably want to talk about a module called "foo"<br>
> > when you ship code or send code over the network you want know<br>
> > *exactly* what you did.<br>
> ><br>
> > The problem with using a module name to identify the code is that the content of<br>
> > the module changes with time and place.<br>
> ><br>
> > In a distributed system we can imagine upgrading code for some module<br>
> > 'foo' bit that foo.erl is *different*on different machine because the<br>
> > code has not yet arrived.<br>
> ><br>
> > Using "just" the module name will and does get you very rapidly into<br>
> > "version nightmare land".<br>
> ><br>
> > Handling versions is much more complicated than you might think - and *nobody*<br>
> > seems to have got it right - (apart from NiX - which might have got<br>
> > things right,<br>
> > but I'm not sure yet)<br>
> ><br>
> > Cheers<br>
> ><br>
> > /Joe<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > > BTW, namespace is probably something Erlang should handle in futur. This would avoid any module name clash. But anither story.<br>
> > ><br>
> > > Le 17 févr. 2016 6:38 PM, derek <<a href="mailto:denc716@gmail.com">denc716@gmail.com</a>> a écrit :<br>
> > >><br>
> > >> that -module(). line sound like redundant, if it can be mismatched,<br>
> > >> why can't it be omitted?<br>
> > >> compiler can derive the module name from the filename anyway; Java<br>
> > >> also made that filename has to match class name, that is a design<br>
> > >> mistake and unnecessary requirement, to my opinion;<br>
> > >><br>
> > >> or on the other hand, if -module() is proved to be useful, why not<br>
> > >> just ignore the filename, and always use what's defined in -module()?<br>
> > >> in many modern language design like Go and Elixir, it's allowed to<br>
> > >> define multiple Class/Module in one file, this will be really<br>
> > >> flexible:<br>
> > >><br>
> > >> %% file1.erl<br>
> > >> -module(module1).<br>
> > >><br>
> > >> %% [content of module1]<br>
> > >><br>
> > >> -module(module2).<br>
> > >><br>
> > >> %% [content of module2]<br>
> > >><br>
> > >> -module(module3).<br>
> > >><br>
> > >> ...<br>
> > >><br>
> > >> On Wed, Feb 17, 2016 at 6:26 AM, Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:<br>
> > >> > Well suppose you sent the *content* of the file in a message - how<br>
> > >> > would the receiver<br>
> > >> > know the name of the module?.<br>
> > >> ><br>
> > >> > Actually the module attribute and file name don't have to be the same - but<br>
> > >> > if they are not you'll break the autoloading mechanism. If the file name and<br>
> > >> > module name are different you should know exactly what you're doing :-)<br>
> > >> ><br>
> > >> > Cheers<br>
> > >> ><br>
> > >> > /Joe<br>
> > >> ><br>
> > >> > On Wed, Feb 17, 2016 at 10:45 AM, Konstantin Vsochanov <<a href="mailto:kost@rol.ru">kost@rol.ru</a>> wrote:<br>
> > >> >> Hi!<br>
> > >> >><br>
> > >> >> I’m working with Erlang for two years now and enjoy every day of using<br>
> > >> >> it. However, there are some strange  features I’m wondering about. One<br>
> > >> >> of them -module() attribute.<br>
> > >> >><br>
> > >> >>  The module name is strictly defined by the name of the .erl file. You<br>
> > >> >> can’t change module name with -module() attribute. But the the -module()<br>
> > >> >> attribute is mandatory. Why? Why we need -module() attribute at all?<br>
> > >> >> Maybe we can make -module() optional in next Erlang release? So we don’t<br>
> > >> >> need to repeat file name in first string of every .erl file. Or maybe I<br>
> > >> >> miss something important?<br>
> > >> >><br>
> > >> >> Feedback is appreciated!<br>
> > >> >><br>
> > >> >> - Konstantin Voschanov<br>
> > >> >> _______________________________________________<br>
> > >> >> erlang-questions mailing list<br>
> > >> >> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> > >> >> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> > >> > _______________________________________________<br>
> > >> > erlang-questions mailing list<br>
> > >> > <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> > >> > <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> > >> _______________________________________________<br>
> > >> erlang-questions mailing list<br>
> > >> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> > >> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>