in reply to Re^2: Exposing minimum required perl version ('use x.y.z') to Perl code during runtime?
in thread Exposing minimum required perl version ('use x.y.z') to Perl code during runtime?

Well, feature.pm could just store the last request. That would be good enough for most cases.

Or the user could simply tell your module what he wants :)

on the one hand, there is no performance benefit between s///r and and the older syntax

on the other hand catering to multiple perl versions seems like busywork

on the other hand ...

perlver - The Perl Minimum Version Analyzer / Perl::MinimumVersion

ha ha :)

  • Comment on Re^3: Exposing minimum required perl version ('use x.y.z') to Perl code during runtime?

Replies are listed 'Best First'.
Re^4: Exposing minimum required perl version ('use x.y.z') to Perl code during runtime?
by sedusedan (Pilgrim) on Apr 03, 2014 at 04:36 UTC

    OK, as usual I'm not expressing myself clearly :) Let's say Data::Sah is just an example. So the performance of s///r, or which version of Perl is most widespread, or which version of Perl to target to to be safe, or Perl::MinimumVersion, all that is red herring.

    What I'm really trying to point out is whether Perl should expose the user's intent of 'use VERSION' to Perl code. And I'm arguing that it should. We can already get version information when user says 'use MODULE VERSION', so why not the case with 'use VERSION'? Aside from my Data::Sah example, I can think of a couple more use-cases where finding out VERSION in 'use VERSION' can be useful:

    1) code analysis -- checking whether user's statement of 'use VERSION' is justified. Here we can use Perl::MinimumVersion to compare what user says she needs and what Perl features she actually uses.

    2) policy enforcement -- we are running some later version of Perl on some servers (say 5.18) but are also running earlier versions (say 5.14), we want to make sure that all code runs under the minimum version and no code says 'use 5.016' or 'use 5.018'. This is of course can also be done using testing/CI, but if Perl can give version information in 'use VERSION', we can also fail on 5.18 test machines.

      $ perl -le " use B::Deparse; use 5.014; print B::Deparse->new->coderef +2text(sub{}) " { use strict; no feature; use feature ':5.12'; }

      So there you have it

      But you say it doesnt have the use statement, well then

      $ perl -le " use B::Deparse; use 5.014; print B::Deparse->new->coderef +2text(sub{ use 5.014; }) " { use strict; no feature; use feature ':5.12'; }

      Oh noes its the same thing ... luckily O

      $ perl -MO=Deparse -le " use 5.014; " BEGIN { $/ = "\n"; $\ = "\n"; } sub BEGIN { require 5.014; } -e syntax OK

      But you say you have to look inside sub O::import ....

      Like I said earlier :) extend use feature to support turning-on-and-documenting all these features ... but I don't see introspection as a necessary part of that api , Deparse can take care of that

      Good luck