perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: version syntax for mp2
Date Mon, 13 Dec 2004 15:37:59 GMT
John Peacock wrote:
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message