develooper Front page | perl.perl5.porters | Postings from August 2001

VERSION in Exporter/MakeMaker/CPAN/Universal

Thread Next
From:
John Peacock
Date:
August 9, 2001 06:57
Subject:
VERSION in Exporter/MakeMaker/CPAN/Universal
Message ID:
3B7296D7.47758475@rowman.com
As part of an earlier discussion started by David Dyck, I suggested 
that I would be up for trying to unify the various VERSION parsing code 
in the core.  I now know I should have kept my mouth shut! ;~)

It is trivial to make Exporter's require_version use UNIVERSAL::VERSION
(which I have already done, but I want to add more tests to be sure it
works 100%), but the other two are much more difficult to deal with 
because they are not actually loading a module (so I don't have a 
package object to play with) as much as comparing various possible 
versions.  I also stumbled across the toke.c code for VStrings, for 
additional code to play with.

Ideally, I would like to implement a scheme where string comparisons
were never employed.  Similarly, I don't think we want to always use 
floating point comparisons, since we cannot do 1.2.3 type versions.
I also think that vstrings, nice though they are, are not suitable
because they also do not specify the number of decimal places for
minor/subversions, so v1.2.3 > v1.2.03, where I think those two are
equivalent (if I understand vstrings that is ;~).

So, my first thought is that we really need a VERSION object, probably 
implemented as an array of IV, so we compare Major, Minor, SubVersion, 
SubSubVersion, etc. as a sequence of integer comparisons.  This would 
nicely deal with the 1.10 < 1.9 issue.  It would make 1.2.3 > 1.2 work
without any grief.  It would not be hard to make Exporter replace the
module $VERSION with a Version object.  Then all version comparisons 
would use the method code automatically, thus simplifying everyone's 
life.  I could even force any module that does not have an explicit 
version to automatically have an apparent version of 0.0.1 (how's that 
Elaine?).

Was this discussed and abandoned when vstrings were added?  I did a
quick search in the archive and discover nothing before 2000-03, where
the vstring code is already in the core.

PROPOSAL - 

I revise and extend UNIVERSAL::VERSION to create objects of type
VERSION with the following behavior:

	v1.2.3	=>	(1,2,3)		# normal version
	v1.2_3	=>	(1,2,0,3)	# beta version < v.1.2.1
	v1.2.3	<	v1.2.29		# my beef
	v1.2	=	v1.2.0		# consistency

When Exporter loads any module, it will silently upgrade the VERSION
scalar in the package to a VERSION object.  Then I will patch MakeMaker 
and CPAN to make use of the code from UNIVERSAL.  Of course, this means 
I need to learn how to use magic to provide my own methods, since I
don't think we want to require that overload be used for ALL modules.
I can already see that I can store a string representation in the PV
(which will be a vstring I guess).

ALTERNATE METHOD

If the above seems too radical or proves to beyond my stale c-coding
ability, we could instead force all version scalars into a standard
format (internally).  For example v1.002.003, which would allow us
to use the existing vstring comparisons.  Users can write what they
want but the internal comparisons happen with three decimal places.

This would require much less coding, but I think it would still mean
extending UNIVERSAL::VERSION and making everything else use that code.

Please take off your cleats before stomping on me; I bruise easily!
;~)

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About