Front page | perl.perl5.porters |
Postings from July 2020
On Wed, 1 Jul 2020 13:26:21 -0500 Todd Rinaldo <toddr@cpanel.net> wrote: > > On Jul 1, 2020, at 7:57 AM, Paul LeoNerd Evans > > <leonerd@leonerd.org.uk> wrote: > > > > On Wed, 1 Jul 2020 07:31:42 -0500 > > Todd Rinaldo <toddr@cpanel.net> wrote: > > > >> I agree that's probably the best way to go. It's a technical debt > >> that makes sense to put off for another day. The same goes for > >> Test2 prototypes. > > > > Can we get you to say this again clearly, for the audience? > > If you want me on record for something, I'll say I think dual life > modules are a bad idea we had to do because perl 5 lasted so long. > I'd rather we stop updating the CPAN version and keep what ships with > Perl. I realize there are counter arguments to this and it's not the > right time so ¯\_(ツ)_/¯ I am not just talking about dual-life modules, but any module that lives on CPAN. For example lets take my List::UtilsBy: https://metacpan.org/release/List-UtilsBy Heavily used by a lot of other things down-river, and definitely currently works before 5.20; probably back as far as 5.8 according to the test matrix. I have had an attempt at providing what I believe is my best effort at fixing this; at providing something by which current perl 5 modules can apply prototypes in a way that still works as valid perl 7 syntax: https://metacpan.org/pod/Sub::Attribute::Prototype Given the huge Caveats section, I am hesitant to even apply this to any of my own modules. > > Are you actually saying that every Perl 5 module should now be > > actively defending itself against a future Perl 7 from causing it > > breakage? > > IMO a dual life (especially something in dist) should be written to > work with the version in blead. The long tail of having to code down > to the supporting a perl written 20 years ago is unsustainable. Yeah; no great complaints from me there. But again I'm not talking about dual-life modules; I'm talking about all of CPAN. Under this current plan of forcing 7-semantics on any perl module without it asking so under "use VERSION" means that every single prototypes-using CPAN module will now be broken trying to run on perl 7. That's a lot of modules. > > And it should be doing so by guessing that 'signatures' is the one > > and only feature that needs to be disabled? > > It's not a guess right? you're using prototypes and the trick of > rewriting the prototype means you can only be compatible back to perl > 5.18. So we have to do this instead. > > no if $] >= 7 feature 'signatures'; And what if perl 7.2 decides that actually the keyword `sub` for anonymous lambda functions is a bad idea, and we should all be spelling it `lambda` instead? Does that mean now I have to go back around everyone one of my CPAN modules that has ever created an anonymous function and put no if $] >= 7.002, feature => "lambda"; This is, again, guessing about what future things a future perl will require my existing code to defend against. > > Are you going to promise that there won't be any more features in > > the future that we'll also have to turn off? > > I'm not promising anything. It is my hope that some day in the > future, enough stuff moves off of 5 that the v5 protocol just gets > dropped from support. Is that next year or next century? No idea. Next century is far off. The announcement was that we'd have perl 7 "within a year, hopefully within six months". This isn't a century-away question. This is me worrying about a lot of code that will break in the next 6 to 12 months. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Previous | Thread Next