Stas Bekman wrote:
Suppose we bundle version.pm in some way with mp2. How is this going to help other modules. Let's say I have a module Foo that requires mp2. How will it check the required version w/o version.pm?
I was thinking that I could provide a version.pm that could be included as a submodule to any package interested in providing the overloaded version objects without resorting to an external dependency. In essence, you would have your own personal version objects (which would just be true version objects if the external version.pm was already loaded, or you were running 5.10.0).
Originally, this came up in relation to Module::Build, which would very much benefit from a unified version object model. But in that case, I would have to be able to provide a pure Perl version.pm, since Module::Build doesn't require a compiler at all now (and that's considered a good thing).
For example, the following shows what I am thinking of (I know that this isn't the way that mod_perl itself actually works, but just play along ;)
... package mod_perl2;
BEGIN { use mod_perl2::version; $VERSION = mod_perl2::version->new("2.2.3"); ... } ...
package some_other_module;
use mod_perl2;
$mod_perl = mod_perl2->new(...);
You meant $mod_perl::VERSION = mod_perl2->new(...);
if ( $mod_perl::VERSION > 2.000 ) # this is now an overloaded comparison
that won't work, simply because there is no mod_perl2 (only mod_perl) and mod_perl.pm coming with mp1 won't have version() bundled, so mod_perl->new will fail.
I think that should work. In other words, you can make your $VERSION scalar an object in your own version class, then control the comparisons through the overloading functionality. And the normal Perl version comparisons happen using whatever code exists. Since you are using the normal
use module 3.0;
style call, it is much easier to intercept the comparison and do what we want with it.
OK
2.00_00? That will make PAUSE skip indexing of the package, due to _.
Oops, I forgot about that bit. I was mostly just saying that a fully floating point notation (since Perl normally ignores the underscore when parsing) was always sufficient for any version of Perl.
i.e. 2.000000
Also didn't you mean 2.000_000 (notice the extra zero):
And yes, I didn't put the right number of zeros. Duh!
:)
John, do you have any good examples on CPAN that use triplets version numbers (but not vX.Y)
I don't actually. I think that version.pm is new enough that there aren't many modules requiring it yet. Once 5.10.0 is out, that is likely to change (for the better, I hope).
Not so sure about that due to the wish to keep backwards compatibility with perl < 5.10. (of course one could require version from CPAN).
Hmm, I'd have thought that it should work with any perl with version, but this doesn't work:
perl-5.6.1 -Mversion -le '$x = version->new(2.0.1); print $x' 0.000
No, the initialization value has to be quoted, because before perl-5.8.1, the v-string code is a lossy transformation (it is impossible to know that the v-string code fired):
$ perl5.8.0 -MDevel::Peek -e '$v = 1.2.3; Dump $v' SV = PV(0x804c540) at 0x806360c REFCNT = 1 FLAGS = (POK,pPOK) PV = 0x805d650 "\1\2\3"\0 CUR = 3 LEN = 4
$ perl5.8.1 -MDevel::Peek -e '$v = 1.2.3; Dump $v' SV = PVMG(0x80845a8) at 0x80659bc REFCNT = 1 FLAGS = (RMG,POK,pPOK) IV = 0 NV = 0 PV = 0x805f610 "\1\2\3"\0 CUR = 3 LEN = 4 MAGIC = 0x8085f00 MG_VIRTUAL = 0 MG_TYPE = PERL_MAGIC_v-string(V) MG_LEN = 5 MG_PTR = 0x805de50 "1.2.3"
That hanging bit of magic means I can posthoc pull the original string representation out and use it, instead of the original PV (which isn't useful anymore). It took me nearly two years to figure out the best way to defang v-strings and make them useful. The version.pm stuff just grew out of that effort.
Understood.
I guess this could have worked for us. So modules could check:
- require 2.x
if ($mod_perl::VERSION >= 2)
- require 2.2.x
if ($mod_perl::VERSION >= 2.002)
- require 2.2.5
if ($mod_perl::VERSION >= 2.002_005)
and this should continue working in 5.10, right?
Exactly. This will work for any version of Perl. It is by far the simplest thing you can do. But it will mean that your distro name won't be the nice version triplet. Personally, I'd rather try and convince you that having the official version.pm external dependency isn't such a bad thing, but I can certainly understand why you would be loath to do that.
right, mod_perl-2.0000001.tar.gz certainly doesn't look good. But that's easily fixable, by making Makefile.PL pass version as "2.0.0" as WriteMakefile(VERSION => "2.0.0"). Then have:
$mod_perl::VERSION = 2.000_000;
and having users use the conditions from above to do the checking.
in fact I think we can switch to that style right now and move to 1.099_018, so moving from RCX to 2.0.0 will be even easier and already tested well.
Perhaps what I can do is pull the latest mod_perl2 files and see if I can demonstrate how things would be different with version.pm or a custom mod_perl::version module. I don't know when I can do that, though, so if you are looking for a timely answer, your best bet is to proceed with floating points all the way.
I've explained above why special bundling (mod_perl::version) won't work, if you require those who need to check mod_perl version to call mod_perl::version() - again simply because if someone requires mod_perl.pm from mp1 it won't have it.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
