develooper Front page | perl.perl5.porters | Postings from March 2021

Re: on changing perl's behavior

Thread Previous | Thread Next
From:
Alexander Hartmaier
Date:
March 30, 2021 09:37
Subject:
Re: on changing perl's behavior
Message ID:
CAB49Qrbz9HNEcPCyL8C+VKk1a+s80qPs1fOddmZoJt5ZvEqZ-g@mail.gmail.com
On Tue, Mar 30, 2021 at 11:15 AM Christian Walde <walde.christian@gmail.com>
wrote:

> The email mentions deprecating and removing of X and opting in a lot
> (which has, as mentioned elsewhere, dubious value).
>
> But one thing i didn't see acknowledged is that for the very determined
> even with explicit versioning there is a thermonuclear option:
>
>         $ perl -v
>
>         This is perl 13[...]
>
>         $ cat test.pl
>         print 1;
>
>         $ perl test.pl
>         This is Perl v13.0.0. Oldest supported version: v7.0.0. Please
> declare version 7 or higher in the first line with: use 7; , stopped at -e
> line 1.
>         BEGIN failed--compilation aborted at -e line 1.
>
> Many people will absolutely and utterly hate this, but the point is that
> for the sufficiently determined perl porter this is always possible at any
> point in the future if and when it is determined that deprecation and
> removals actually provide benefits.
>
> This means that nobody needs to worry that requiring versioning also means
> maintaining Perl 5 forever, as that's not a thing.
>

Handling it that way was also my idea when reading through lots of the
current email.
Raku has its version syntax for exactly that reason and they currently
support 6c, 6d and what will eventually become 6e.
As it is quite young they haven't had the need to remove the support for 6c
but that might happen sometimes in the future.

For (larger) applications I don't see a problem with specifying the Perl
version explicitly in each module and testing compatibility when upgrading
to a newer Perl version.
As it's easy to compile your own Perl and containers are a thing you can
package your application in a container with whatever ancient Perl version
it needs and be good.
That's still an unsupported application using an unsupported Perl version
with possible security vulnerabilities then.

For CPAN modules a solution for really long-term support, as in 10+ years,
is way harder to find. But that largely depends on how long Perl (the
interpreter) supports an older version.

What do you think about a dumbed down Perl 5 variant for system scripts,
oneliners, etc. that is used when no version is specified in a package and
which will be supported longer (I don't dare to write 'forever')?

Best regards, Alex

-- 
> With regards,
> Christian Walde
>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About