[erlang-questions] Strings - deprecated functions
Robert Virding
rvirding@REDACTED
Mon Nov 27 03:03:06 CET 2017
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171127/fba71066/attachment.htm>
More information about the erlang-questions
mailing list