Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
demerphq
Date:
June 26, 2020 15:11
Subject:
Re: Announcing Perl 7
Message ID:
CANgJU+XMP5dBF=y74yCER3SvE-qNq6fhXDejkgV=4yXYQidHDQ@mail.gmail.com
On Fri, 26 Jun 2020 at 15:46, Dave Mitchell <davem@iabyn.com> wrote:
>
> On Fri, Jun 26, 2020 at 02:49:31PM +0200, demerphq wrote:
> > To achieve this change requiring new code to include "use v7" is a
> > non-starter.
>
> This is the bit I fundamentally don't understand. Convince me of this,
> and most of my objections will fizzle away.
I think perhaps we are at cross purposes here.
The objective "I wish boilerplate free perl code to stick to the most
modern interpretation of that code" is incompatible with "you must add
boilerplate to get the latest version of the code".
> In my world, the big first public release of 7.0.0 will come along with
> lots of explanations and docs all saying that "if you are writing modern
> perl, then the first thing you need to do is add 'use v7;' to the top of
> your script" - in the same way that 'use strict; use warnings' has been
> the mantra for the last 20 years.
>
> People learning perl for the first time will know nothing other than to
> add 'use v7'. People working for big companies with coding standards
> will be told to put 'use v7' at the top of each script.
>
> Meanwhile, people's existing code which doesn't have a 'use vx.y.z' at
> the top won't gratuitously break right now.
My understanding is any existing code which has "use strict;" will be
fine as "use strict" will be the same "use perl5-semantics" or
whatever the syntaxt will be. Thus relatively little will break. The
code that will break will be scripts like
```
$x= rand();
```
because strict will be implied by default. So that needs to be written:
```
my $x= rand();
```
I think relatively little code will break and that which does which is
important will end up with new maintainers and new lease on life
because of it.
> There is nothing to stop us from, in 5 years say, making the latest
> release of of perl putting out an automatic warning along the lines of
>
> warning: this script doesn't include a 'use vx.y.z'
>
> header, then some time later making it fatal.
I don't say you are wrong, but it doesn't achieve the objective Sawyer
wants, which is that baby perl, where you do not specify the semantics
you desire, follows the most modern coding practices.
> Then there's nothing to stop a later release of perl from croaking
> if the vx.y.z doesn't match some minimum we've decided.
>
> There's nothing to stop us in X years time that saying the next release of
> perl won't support indirect object syntax or whatever.
>
> In short, lets break things as and when there's a good reason to do so,
> rather than break things gratuitously.
I understand what you are saying, but I think saying "gratuitous" is
unfair to Sawyer. I think he is doing this with a good reason and he
has an objective which IMO means it is not gratutious. I understand
you do not feel the objective is worth the cost, but I think it is
unfair to characterize it as gratuitous, and we should be careful not
inflate the scale of that cost. My experience of code at work is that
very little omits use strict and that which does I would be quite
happy to have it start being executed as though strict was on. I doubt
most of it would compile.
So basically to me all you are doing is moving this breakage long into
the future to give all these scripts yet more time to catch up with
modern perl coding practices. I am not convinced its worth the wait. I
think there are relatively few scripts proportionally speaking that do
not use strict, and I think most of the affected existing scripts will
just fail to compile under the new rules, and the ones that do compile
will behave the same as they used to. So I think the scope of this
issue will be relatively small in proportion.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next