in reply to Re^5: Why eval $version?
in thread Why eval $version?

our $VERSION = "0.001"; $VERSION = eval $VERSION;

The thing I don't like about this is that (depending upon the original string), you might find that, after the eval is done, "$VERSION" ne <original_string>
No such problem with "0.001", but consider this simple script: 
use strict;
use warnings;

my $str = "2.30";

our $VERSION = $str;
$VERSION = eval $VERSION;

print "WTF\n" if $VERSION ne $str;

[download]
That outputs "WTF".
That is, having assigned the string "2.30" to $VERSION, the eval forces $VERSION into a state where it stringifies to something other than "2.30" - namely to "2.3".

It's probably of little importance, but I found it annoying enough to immediately replace all occurrences of eval $VERSION in my .pm files with #eval $VERSION
I've no regrets about having done that, yet.

Notably, with the eval removed, we can then perform both numeric and string comparisons reliably: 
use strict;
use warnings;

my $str = "2.30";

our $VERSION = $str;
print "OK 1\n" if $VERSION == 2.3;
print "OK 2\n" if $VERSION == $str;
print "OK 3\n" if $VERSION eq $str;
print $VERSION, " ", $str, "\n";
print "$VERSION $str\n";

__END_
outputs:
OK 1
OK 2
OK 3
2.30 2.30
2.30 2.30

[download]
I find that saner and preferable ... though I now always avoid using version strings that terminate with one or more zeros ... just in case ;-)

Cheers,
Rob

Replies are listed 'Best First'.
Re^7: Why eval $version?
by Haarg (Priest) on Jul 09, 2020 at 18:28 UTC

    The generally recommended practice now is to use $VERSION =~ tr/_//d; rather than $VERSION = eval $VERSION. This removes the underscores, but leaves trailing zeros intact. This also only applies if you are using numeric versions (rather than three part versions like v1.2.3) and are using underscores to denote developer releases. Using -TRIAL releases is another option that many prefer rather than using underscores.

[reply]
[d/l]
[select]
      The generally recommended practice now is to use $VERSION =~ tr/_//d;

      A much better idea, IMO.
      And, if I ever release another devel version of a module, that's what I'll use.

      Cheers,
      Rob

      PS
      I haven't been releasing devel versions for a while now.
      Apparently, not all smokers test devel releases, and it was not uncommon for me to have the devel version pass everywhere, only to fail on some other smoker as soon as it became a stable release.
      I couldn't see the point in that. Instead, I choose to do broad based testing locally and then do a stable release.
[reply]
[d/l]
Re^7: Why eval $version?
by LanX (Saint) on Jul 09, 2020 at 15:42 UTC
    Hi

    2 things

    • make-maker and other tools are statically parsing perl files for $VERSION = "numberwang" so your example with $str won't work.
    • the comparison is supposed to be numeric, it's no surprise that string comparison will often fail on numbers! Just try sort 8..12 to see what I mean. °

    I'm afraid make-maker is keeping us stuck with $VERSION syntax for backwards compatibility.

    see also davido's research: Re: Why eval $version?

    But I could imagine a module Version::Smart exporting a tied object in $VERSION which DWIM.

    Though I'm wary of XKCD's standards ...

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

    Update

    °) yes I know, since it's quoted it looks like a string

[reply]
[d/l]
[select]
      it's no surprise that string comparison will often fail on numbers! Just try sort 8..12 to see what I mean

      Yes - and that's the reason we compare them in numeric context.

      It's just that if I assign a version as "2.30" I like it to print as "2.30", not "2.3".
      Otherwise I would have saved myself the keystroke and assigned "2.3".
      And to check on that, I generally run a test that $VERSION eq "2.30" - which of course fails if I eval $VERSION.

      As I said, it's not a big deal.
      It annoys me that the string I assigned is being changed ... so I simply avoid the procedure.

      Cheers,
      Rob
[reply]
[d/l]
        Frankly, both string and float are crippled concepts here and all those problems stem from bad compromises on the expanse of boilerplating and tribal knowledge.

        What we really want and need is a tuple of integers, which stringifies to a dotted number and compares numerically.

        I'm going to have a look at this version object tomorrow to see if it does the right overloads.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

[reply]

In Section Seekers of Perl Wisdom