<div dir='auto'><div>Hi,<div dir="auto"><br></div><div dir="auto">If Erlang had namespaces we could imagine old strings function if no namespace,  for old code compat, while new code could use same functions names, but with a namespace. Let say -namespace(strings, pref1, "http://www.erlang.org/strings/utf8"). In header.</div><div dir="auto"><br></div><div dir="auto">When using functions with mixed namespaces,  Use of a prefix would solve the problem. </div><div dir="auto"><br></div><div dir="auto">pref1::strings:func() for new utf8 module or strings:func() for legacy latin1 ones.</div><div dir="auto"><br></div><div dir="auto">This would also solve the very complicated problem of module name clashes from different repositories...</div><div dir="auto"><br></div><div dir="auto">Regards </div><br><div class="gmail_extra"><br><div class="gmail_quote">Le 23 nov. 2017 11:00 PM, Joe Armstrong <erlang@gmail.com> a écrit :<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">On Thu, Nov 23, 2017 at 9:39 PM, Michał Muskała <michal@muskala.eu> wrote:<br>
><br>
> On 23 Nov 2017, 17:35 +0100, Joe Armstrong <erlang@gmail.com>, wrote:<br>
><br>
> I agree 100%<br>
><br>
> If you make major changes to a library module that been around for a very<br>
> long<br>
> time you will break a lot of old code.<br>
><br>
> At a first cast<br>
><br>
> It's OK to add new functions to the module<br>
> It's ok to fix bugs in old functions with changing the names<br>
><br>
> But it NOT ok to remove functions or change the semantics of existing<br>
> non-buggy functions.<br>
><br>
> It's not as if we'll run out of module names soon. Call the new module<br>
><br>
> strungs_v1 strings_1 or better_strings or strings_improved or<br>
> anything you feel like but<br>
><br>
><br>
> While this sounds great, I will argue that it's not very practical. The<br>
> primary problem is that somebody has now to maintain both versions of the<br>
> code.</p>
<p dir="ltr">Why maintain the old version?  As soon as there is a strings_v1 exist<br>
then changes can be made there</p>
<p dir="ltr">> And there are situation when even old code needs to change - the<br>
> particular case we're probably all agree with is when security issues are<br>
> discovered.</p>
<p dir="ltr">Possibly - you could alwys issue a very strong compiler warning<br>
"security problem in strings" please change to strings_v1<br></p>
<p dir="ltr">> If the team (which we assume is of fixed size) spends their time<br>
> maintaining old code, they don't spend time developing new features.<br>
> Resources are unfortunately limited.<br>
><br>
> Another downside of keeping all old implementations is that it decreases<br>
> readability of code. Code is read much more often than written and should be<br>
> optimised for reading.</p>
<p dir="ltr">It should be but isn't - look at the history of erl_scan the first versions were<br>
very readable - later versions were heavily optimised and far less readable</p>
<p dir="ltr">>  But now, each time I see strings:tokens/1 and<br>
> strings_v1:tokens/1 I need to decide if they actually do the same when<br>
> reading the code.</p>
<p dir="ltr">You could always write in strings_v1.erl</p>
<p dir="ltr">    tokens(X, Y) -><br>
         strings:tokens(X, Y).</p>
<p dir="ltr">and it would be abundantly clear - or use a  parse transform.<br></p>
<p dir="ltr">> And I need to do this every time I read the code. The same<br>
> distinction is needed during an upgrade, but it's needed only once.</p>
<p dir="ltr">I still maintain that things with the same name must be the same.<br>
As soon as you get two versions of strings offering different<br>
functions then the name of the module 'strings.erl' becomes<br>
ambiguous.</p>
<p dir="ltr">You have to say "I mean the version of strings in version 19.2 of Erlang"<br>
Oh dear I thought you meant version 45.3"</p>
<p dir="ltr">If we use a name we should not have to qualify it by either the date<br>
when the name was valid or by the checksum of the Git commit in which<br>
it can be found.</p>
<p dir="ltr">Imagine what would happen if I could change my name on an arbitrary date</p>
<p dir="ltr">I was talking to joe the other day, when? 12 June 2015 - Oh you mean<br>
when he was called<br>
fred - No that was later he changed his name to Donald on the 23 th August 2016.</p>
<p dir="ltr">And what, is wrong with names like srings_vsn1, string_vsn_2 etc. it's<br>
not as if the<br>
integers are going to run out.<br></p>
<p dir="ltr">One thing I've always hated about revision control systems like GIT is<br>
that the same name<br>
means different things in different commits. This causes no end of<br>
confusion and many errors.</p>
<p dir="ltr">Breaking peoples code by changing changing the libraries I view as a<br>
fundamental sin.</p>
<p dir="ltr">After a few iterations you'll end up with two mutually incompatible<br>
versions of a library<br>
with the same name. One will export a with you want to use, the other<br>
b which you also want to use.<br>
But you cannot use both.</p>
<p dir="ltr">I have seen this in virtually every system I've every programmed.</p>
<p dir="ltr">Just invent a new name if you change things.</p>
<p dir="ltr">How difficult can that be?</p>
<p dir="ltr">/Joe<br></p>
<p dir="ltr">><br>
> Michał.<br>
_______________________________________________<br>
erlang-questions mailing list<br>
erlang-questions@erlang.org<br>
http://erlang.org/mailman/listinfo/erlang-questions<br>
</p>
</blockquote></div><br></div></div></div>