[erlang-questions] Strings - deprecated functions

[Eric des Courtis]

While I feel the pain of Joe having suffered countless hours fixing
deprecation in various old libraries. I have to say there is something to
be said for throwing things away.

I can't help but think I can have my cake and eat it too. Maybe something
like a transpiler to compile old Erlang to new Erland and keep the Erlang
VM lean?

On Thu, Nov 23, 2017 at 5:35 PM, Éric Pailleau <eric.pailleau@REDACTED>
wrote:

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