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


Thread Next
Felipe Gasper
July 2, 2020 10:54
Message ID:

> On Jul 2, 2020, at 00:47, Tom Molesworth <> wrote:
>> On Wed, 1 Jul 2020 at 18:50, Felipe Gasper <> wrote:
>> I’m going to pick on AE since it’s a useful “poster-child” of a popular module that we know will break with the v7 feature set that I think many would like.
>> Since there is no “Perl 7” code that exists currently, maybe have Perl 7 code explicitly mark dependencies that need v5.x features? That way CPAN is 100% accessible to both v5 and v7.
> Some potential arguments against this:
> - anyone trying to use a CPAN module - presumably still a use-case which we'd want to support? - now has to write `use v5 Some::CPAN::Module` or equivalent

That’s the suggestion, yes.

> - this breaks if a new version of the module is uploaded which *does* switch to Perl7 defaults

If the new module does “use v7” that could override.

> - it needs to be recursive, applying to all modules loaded by that module...


> - so, what if your Perl5 module now tries to use a core module, or dual-life such as List::Util?

Since “use v5” is recursive that should work.

> - doesn't improve the situation for scripts and app-level code, those would need to be changed

That seems to be the nature of the notion of v7 in the first place.

> Effectively you've moved from a single `use v7` line of boilerplate, to multiple hard-to-maintain lines dictating which rules apply to 3rd-party code?

The idea is to “reward” use of more modern code while still facilitating use of stuff that needs v5. If I have to explicitly enable an emulation layer to use AE, that’ll encourage either use of an alternative solution or an update to AE.

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About