[erlang-questions] Strings - deprecated functions

[Eric des Courtis]

On Fri, Nov 24, 2017 at 9:40 AM, Loïc Hoguin <essen@REDACTED> wrote:

> On 11/24/2017 03:07 PM, Eric des Courtis wrote:
>
>>  From my perspective, we want the following things:
>>
>>   * The libraries to stay simple, small and clean (that means throwing
>>     away things)
>>   * Our old code to continue to work without modifications (that means
>>     having a mechanism for compiling old code targetting new versions of
>>     Erlang)
>>
>
> 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.
>
> For example removing ciphers or hashes in crypto requires human
> intervention on every code bases that require them.
>
> Another issue comes from old code requiring syntax or VM features that
> have been removed.
>
> Then you have issues where it is technically still possible to do the old
> functionality, but the performance or memory aspects are not equivalent.
>
>   * To mix old and new Erlang code together
>>
>
> 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.
>
> You'll want to do this even if OTP team go out of their way to make sure
> everything stays compatible forever.
>
> I see no reason why we can't have both. What I am not okay with is:
>>
>>   * Endlessly growing libraries of functions that are there for legacy
>>     reasons (wasting space and confusing new developers)
>>   * Fixing libraries over and over again because something got marked
>>     deprecated
>>
>> So how do we get both?
>>
>
> You don't.
>
> In fact your second point is incorrect: there's absolutely no reason to
> fix a library because something got marked deprecated.
>
> Zero.
>
> Developers should not "fix" libraries when something gets marked
> deprecated. Developers should *take notice* that something has been
> deprecated.
>
> 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...
>
> The time to fix comes when the feature gets *removed* or is rendered
> *incompatible*. (Or soon before that actually happens, anyway.)
>
> 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.
>
> 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?
>
> 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).

That is what I meant.

>
>
> --
> Loïc Hoguin
> https://ninenines.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171124/f1b5861f/attachment.htm>