develooper Front page | perl.perl5.porters | Postings from June 2020

Re: Announcing Perl 7

Thread Previous | Thread Next
From:
Darren Duncan
Date:
June 30, 2020 06:00
Subject:
Re: Announcing Perl 7
Message ID:
7e3c11d6-a112-fe53-e6fa-826cfb158f7e@darrenduncan.net
On 2020-06-29 10:40 p.m., Tom Molesworth wrote:
> On Tue, 30 Jun 2020 at 13:33, Darren Duncan wrote:
> 
>     On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-porters wrote:
>      > So one concern that does not seem to have been addressed by the "enable by
>      > default" proposal is "what about CPAN". It used to be a selling point for
>     Perl,
>      > would be a shame to lose that.
> 
>     Well I DID say that CPAN is one of those places where explicit versions SHOULD
>     be used.  And if any don't, well CPAN is public, and as you demonstrated we can
>     see what would break.  And so we now are in the position to fix those modules.
> 
> Fix... how? They aren't broken until we change the rules, some of them haven't 
> had a release in years, and are you suggesting that p5p takes responsibility for 
> unilaterally releasing patched versions? Ignoring licenses and any other 
> concerns, seems like a lot of work - and that hasn't even happened in the past 
> for dual-life modules, look at the cases where *core Perl* releases with 
> "development versions" of important modules because there's a patch that is not 
> yet on CPAN. Have a look at the Scalar-List-Utils sorting discussion from not 
> too long ago - even when there's a working patch, it's not always trivial to 
> ensure that it makes it into a stable release.
> 
> With limited available resources, and a long list of things to be done - many of 
> which are the subject of separate threads which haven't even started yet - it 
> would seem safer to avoid a big "release all the modules" project. Maybe some 
> more advanced patching option is something that the toolchain is already working 
> on...

Fix means make compatible.  And the argument is for the community at large to do 
it, not just those who maintain the Perl interpreter.

I recall various comments that the Perl 7 announcement has lit a fire under the 
wider Perl community and a lot of people are chomping at the bit to help the 
effort.  Well providing compatibility updates to modules is a good use of that.

Lots of modules are in public version control and people wanting to help can 
submit pull requests for them.  This has happened over the years anyway.

A low-hanging fruit is that if anything doesn't work with use strict it is 
updated to declare its variables and so on.

Personally I do NOT advocate that signatures or anything likely to change be 
turned on by default, but simpler things unlikely to change should be like "say".

-- Darren Duncan

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