One can use _ as delimiter in long literal numbers but not when numifying strings
Yes- that's pretty much the point I was making.
However, I wasn't sure if the need to eval comes about solely by introducing an underscore, so I chose to specify the strings that don't require eval rather than the strings that do.
I had wondered whether eval might also cater for version strings that contain multiple decimal points (v-strings), but a quick check suggests that's not the case. (Someone please let me know if I've got that wrong.)
Cheers, Rob | [reply] |
> I had wondered whether eval might also cater for version strings that contain multiple decimal points (v-strings),
The last part of dagolden's summary recommends to avoid dotted-integer versions
Given these criteria, my recommendation is to use decimal version numbers, put them in quotes, and add a string eval:
our $VERSION = "0.001";
$VERSION = eval $VERSION;
This is safe and effective and always works. By putting any $VERSION in quotes, even if it isn’t an alpha, you don’t have to remember to add them if you ever change to an alpha version. (And numbers with trailing zeroes are nicely formatted when parsed for distribution versions.)
If you really want to have a dotted-integer module version, then I strongly recommend that you limit your module to Perl 5.10 (or require version.pm and at least Perl 5.8.1) and that you never use an alpha version number. Always quote your dotted integer version when you define it and always use a leading-v to guide your users towards proper usage.
It’s unfortunate that version numbers are so complicated in Perl, but if you follow the recommendations in this article, your version numbers will be as boring as possible. And if you’ve read this all the way to the end, I hope I’ve convinced you that ‘boring’ version numbers are exactly what you want.
| [reply] |
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;
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
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
| [reply] [d/l] [select] |
I read dagolden's article thrice and my head keeps smoking because of the confusion.
| [reply] [d/l] [select] |
++ on both posts, except why would one group the fractional digits as "3.202_007_29" rather than as "3.2020_07_29", which seems much more intuitive to me?
Give a man a fish: <%-{-{-{-<
| [reply] [d/l] [select] |
I followed the 3 digit convention, but since _ is primarily used to distinguish dev releases, it might be inappropriate using more than one here.
| [reply] [d/l] |