[erlang-questions] Strings - deprecated functions

[bengt e]

Greetings,

It would be nice if Erlang modules where prefixed with their app. The new
functions would then be in stdlib_strings, instead of string. I know that
this would only help once, ie when functions in stdlib_strings are
deprecated we would have the current problem again. But that would be in 20
years time, right? Perhaps a better idea has come up by then.


bengt

On Mon, Nov 27, 2017 at 3:03 AM, Robert Virding <rvirding@REDACTED> wrote:

> I think it is perfectly possible to keep the old functions in the same
> 'string' module in a clean way if you just reorganise the documentation.
> Now all the functions, both the new and the obsolete, are kept in one
> alphabetical list which makes it difficult to see which are which and get a
> clear overview of the functions. Why not just separate the functions into 2
> groups, the new and the obsolete, each in its own alphabetical list? This
> would make it easy to keep the old functions while making it easy for
> people to choose the newer ones, and migrate code if desired. There would
> then be no need to get rid of the old functions and break backward
> compatibility.
>
> Robert
>
>
> On 25 November 2017 at 15:10, Jesper Louis Andersen <
> jesper.louis.andersen@REDACTED> wrote:
>
>> I think the only way to approach a problem like this is by asking:
>>
>> "How much are you willing to spend on your backwards compatibility?"
>>
>> Maintaining a long-term-release of a piece of software is no easy feat.
>> It requires effort, and that requires money. If you need stability from an
>> older release and you need control of that release, you have to give the
>> right people some money.
>>
>> In Solaris, Sun had the advantage that they could use the Zone
>> construction in the OS. You could brand a zone, such that inside the zone,
>> the Solaris (10) system operates as if it were a Solaris 8 or 9 system.
>> This is achieved by manipulating the syscall table of the kernel and
>> handling some syscalls differently. Maintenance of such a compat layer is
>> time-consuming, however. In FreeBSD, you have libcompat for much the same
>> thing: It provides you with a way to run legacy binaries on a new system
>> for a while, so you don't have to upgrade all of your software in one go.
>>
>> In Android development, the system runs by "API levels" (corresponding
>> somewhat to Erlang/OTP major releases). A given library functionality is
>> *introduced* at some API level, *deprecated* at a higher level and
>> eventually *removed* in an even higher API level. This means that any
>> function is alive over a "window" from introduction to removal.
>>
>> In practice, one has to cope with changes of a system over time. What is
>> a problem is the rate-of-change, not the change itself. Historically,
>> Erlang is a fairly slow-changing system I think. My older Haskell code
>> rarely compiles, and the recent changes in OCaml also requires far more
>> interaction to make things work again on some code bases.
>>
>> The changes are likely to require library maintainers to handle several
>> releases and this is where the hard part of the work is. A single project
>> can target a single Erlang release. A library, which may have to span
>> several Erlang releases
>>
>> * Cannot use a new function when it is introduced. That would break
>> backwards compatibility.
>> * Cannot use functions which have been removed. That would break forwards
>> compatibility.
>>
>> How large a deprecation window can be depends largely on factors such as
>> "how common is the function, and how easy is it to change the code?", "Do
>> we have a sponsor who wishes the older versions kept around, paying us to
>> do so?", and so on. You may quickly find it is cheaper for you to upgrade
>> the Erlang/OTP release rather than maintaining and older version of it.
>>
>>
>>
>> On Sat, Nov 25, 2017 at 2:50 AM <ok@REDACTED> wrote:
>>
>>> A couple of years ago I was working through a Java book.
>>> Not one of the examples got a clean compile.  Not one.
>>> oddly enough, it was string-handling functions that had
>>> been deprecated, and oddly enough, in my environment the
>>> old functions still did everything I needed.
>>>
>>> It's not just Erlang and Java.  I had C code using some of
>>> the classic string functions in ways I had carefully ensured
>>> were correct.  Porting to the next version of the Unix
>>> flavour I was using, the linker screamed at me about unsafe
>>> functions.  Since I wanted other people to use the program
>>> and didn't want them looking down on me, I spent a merry
>>> couple of hours changing the code to use memcpy instead of
>>> strcpy and so on.
>>>
>>> Again, I have a program which works fine in Solaris 10, Open
>>> Solaris, and Solaris 11 Express.  It uses a mix of old
>>> functions (hey, if the code still works, why change it, am I
>>> right?) and new functions (if you can call POSIX 2008 "new".)
>>> But OpenIndiana?  I am still baffled as to what combination of
>>> feature test macros I can set to make the program compile, and
>>> am coming to the conclusion that there isn't one.
>>>
>>> Did I mention the trouble I've been having with Ubuntu 17.10?
>>> I'll spare you that, but let's just say that putting standard
>>> headers in nonstandard places really really does not help.
>>>
>>> I don't really have a solution.  It seems as though the only
>>> thing you can do to ensure that old code continues to work is
>>> to keep a VM imagine with a complete copy of the environment
>>> it used to work in.
>>>
>>> Good luck plugging new libraries into that, though.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171127/8291f3d8/attachment.htm>