Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
David Mertens
Date:
June 29, 2020 19:59
Subject:
Re: Announcing Perl 7
Message ID:
CA+4ieYVUbUiLCh+Ea537fy1zVc6_Qsq+bASrqt_z_9riCuca9g@mail.gmail.com
On Mon, Jun 29, 2020 at 5:05 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:
> On Mon, 29 Jun 2020 09:56:10 +0100
> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
>
> > Todd, please explain how github's syntax highlighter checks the value
> > of $] when highlighting a .pm file.
> >
> > Or for that matter even metacpan.org. How will our own infrastructure
> > know what version of perl syntax rules to be using when highlighting
> > our own code?
>
Metacpan, at the very least, could check the distribution's metadata for
the major version(s) of Perl on which the code will install.
> Also for that matter; how will perlcritic/perltidy know?
>
If we require a back-compat module, then it's trivial. If we use file
extensions, it's also trivial.
> I surely hope we are not going to end up with source-code tooling that
> presumes that the version of Perl *running* the tooling must equal the
> version of Perl that source code targets. I would hate to have to run
> all of my tooling under perl5 just because I am working on a .pm file
> that needs to be dual-life and target perl5 as well as perl7.
>
What's wrong with that assumption? Also, I'm not sure exactly what tooling
you're talking about, but surely perlcritic and perltidy could be given
command-line switches to use the "other" version of Perl, right?
I strongly suspect that the vast majority of Perl code will run fine under
Perl 5 and 7. Subroutine signatures appear to be an interesting corner
case, but I don't see why that needs to hold up the parade here.
David
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
Thread Previous
|
Thread Next