<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 24, 2017 at 9:40 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/24/2017 03:07 PM, Eric des Courtis wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
From my perspective, we want the following things:<br>
<br></span>
* The libraries to stay simple, small and clean (that means throwing<br>
away things)<br>
* Our old code to continue to work without modifications (that means<span class=""><br>
having a mechanism for compiling old code targetting new versions of<br>
Erlang)<br>
</span></blockquote>
<br>
That can work in many cases but not in the general case. This only works for a specific set of changes where an equivalent still exists in the code base.<br>
<br>
For example removing ciphers or hashes in crypto requires human intervention on every code bases that require them.<br>
<br>
Another issue comes from old code requiring syntax or VM features that have been removed.<br>
<br>
Then you have issues where it is technically still possible to do the old functionality, but the performance or memory aspects are not equivalent.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* To mix old and new Erlang code together<br>
</blockquote>
<br>
If it's maintained, no problem. If not, even if it compiles and runs you should probably make sure to have a good set of tests to know it still works as intended.<br>
<br>
You'll want to do this even if OTP team go out of their way to make sure everything stays compatible forever.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I see no reason why we can't have both. What I am not okay with is:<br>
<br></span>
* Endlessly growing libraries of functions that are there for legacy<span class=""><br>
reasons (wasting space and confusing new developers)<br></span>
* Fixing libraries over and over again because something got marked<span class=""><br>
deprecated<br>
<br>
So how do we get both?<br>
</span></blockquote>
<br>
You don't.<br>
<br>
In fact your second point is incorrect: there's absolutely no reason to fix a library because something got marked deprecated.<br>
<br>
Zero.<br>
<br>
Developers should not "fix" libraries when something gets marked deprecated. Developers should *take notice* that something has been deprecated.<br>
<br>
There's nothing to fix to begin with! Check your OCD levels and stop trying to get rid of all the deprecation warnings with obscure parse transforms or version-specific defines...<br>
<br>
The time to fix comes when the feature gets *removed* or is rendered *incompatible*. (Or soon before that actually happens, anyway.)<br>
<br>
As far as the string module is concerned, there's absolutely no need to spend efforts to make your code run for both the old and the new string module because the functions will not be removed for a very long time. And until they are, chances are you will stop supporting OTP versions before the new functions were introduced. You can do the changes THEN.<br>
<br>
I am baffled every time someone opens a ticket telling me that I have deprecation warnings. I know! But they're harmless and the code works on all supported versions, so why would I spend efforts to remove it?<br>
<br>
Your question can be reframed to be about an endlessly growing library + having to fix libraries when things get removed, which is more of a choice, you can't really have both. Either you have an endlessly growing library, or you remove functions and fix libraries (manually or otherwise).</blockquote><div>That is what I meant. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Loïc Hoguin<br>
<a href="https://ninenines.eu" rel="noreferrer" target="_blank">https://ninenines.eu</a><br>
</div></div></blockquote></div><br></div></div>