Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

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

by sedusedan (Monk)
on Apr 02, 2014 at 08:44 UTC ( [id://1080700]=note: print w/replies, xml ) Need Help??


in reply to Re: 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.
  • Comment on Re^2: Exposing minimum required perl version ('use x.y.z') to Perl code during runtime?

Replies are listed 'Best First'.
Re^3: Exposing minimum required perl version ('use x.y.z') to Perl code during runtime?
by Anonymous Monk on Apr 02, 2014 at 09:22 UTC

    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 :)

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1080700]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (None)
    As of 2024-04-25 01:43 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      No recent polls found