Front page | perl.perl5.porters |
Postings from July 2020
From: Felipe Gasper
July 2, 2020 10:54
Message ID: F0CC4DFF-58F5-4464-84C9-180D90E868D0@felipegasper.com
> On Jul 2, 2020, at 00:47, Tom Molesworth <firstname.lastname@example.org> wrote:
>> On Wed, 1 Jul 2020 at 18:50, Felipe Gasper <email@example.com> 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.
by Felipe Gasper