version object updates
John Peacock
implementation of my version patches. Now both Sarathy and I can get what we
want: if the version object is created using a bare [floating point] number it
will parse the way that Sarathy expects:
$v = new version 1.2; # this is version 1.200
and if the version object is created using either a vstring (Perl 5.9+) or else
something that resolves to a PV, it will parse the way I want:
$v2 = new version ((qw$Revision: 1.2$)[1]); # this is version 1.2
and additionally, I added some logic such that the following relations hold true:
1.2 == 1.2.0 == 1.2_0 < 1.2_1 < 1.2.1
I'll try and release the new code to CPAN tonight.
The problem I have discovered is that in order to implement this in bleadperl, I
have to patch toke.c:S_force_version() and op.c:Perl_utilize() to recognize
version objects, so that
use ExtUtils::Constant 0.11 "WriteConstants"
works naturally. Of course that causes additional concerns, since the 'use'
line only accepts bare numbers (i.e. not quoted strings). I don't know if I am
up to the task (even with the Cozens & Jenness in hand). We'll see.
In any case, I am leaving for Wisconsin on Friday `til the end of the year (yes,
voluntarily ;~), so I am not going to finish this until January. Anyone who is
interested can check out the CPAN version and you can argue amongst yourselves
until then...
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
John Peacock
> Anyone who is interested can check out the CPAN version and
> you can argue amongst yourselves until then...
The uploaded file
version-0.25.tar.gz
has entered CPAN as
file: $CPAN/authors/id/J/JP/JPEACOCK/version-0.25.tar.gz
size: 10772 bytes
md5: 335ef8fe02b74ee36310cdb23691f718
Share and enjoy!
Paul Marquess
> I couldn't sleep last night so I got up early and hacked together
> a better
> implementation of my version patches. Now both Sarathy and I can
> get what we
> want: if the version object is created using a bare [floating
> point] number it
> will parse the way that Sarathy expects:
>
> $v = new version 1.2; # this is version 1.200
Does that mean that this is the case?
1.10 < 1.2
Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
John Peacock
> Does that mean that this is the case?
>
> 1.10 < 1.2
>
Depends; are you talking about version objects or the parameters, also whether
the parameters were quoted:
version->new(1.10) < version->new(1.2) # 1.100 < 1.200
version->new("1.10") > version->new("1.2") # 1.010 > 1.002
This is actually why I don't like treating the quoted version different than the
unquoted. However, if Sarathy insists that 1.10 => 1.100 and not 1.010, there
is going to be a discontinuity.
Paul Marquess
> > Does that mean that this is the case?
> >
> > 1.10 < 1.2
> >
>
> Depends; are you talking about version objects or the parameters,
> also whether
> the parameters were quoted:
>
> version->new(1.10) < version->new(1.2) # 1.100 < 1.200
> version->new("1.10") > version->new("1.2") # 1.010 > 1.002
>
> This is actually why I don't like treating the quoted version
> different than the
> unquoted. However, if Sarathy insists that 1.10 => 1.100 and not
> 1.010, there is going to be a discontinuity.
UGH! The term "can of worms" springs to mind.
John Peacock
>
> UGH! The term "can of worms" springs to mind.
>
And is that a vote for my way of parsing versions?
To my mind the logic goes like this:
For Perl5.9.0 and later, the following two versions are equivalent:
$v1 = new version 1.2.3; # that is a v-string
$v2 = new version "1.2.3"; # that is a string
and both are resolved as 1.2.3 (or 1.002003 when numified). The decimals are
treated strictly as delimiters (and any leading zeros are not significant).
Consequently, I believe that the following two should also be equivalent:
$v3 = new version 1.2; # that is a number
$v4 = new version "1.2"; # that is a regular string
and both are resolved as 1.2 (or 1.002 when numified). Unfortunately, this
conflicts with Sarathy's belief that the first should be read as 1.200 instead.
I thought I had a narrow special case that would grandfather the way that Perl
versions were handled prior to 5.6.0, but that wasn't enough, or my arguments
were not strong enough.
:~(
Paul Marquess
> Paul Marquess wrote:
> >
> > UGH! The term "can of worms" springs to mind.
> >
>
> And is that a vote for my way of parsing versions?
Let me scan the p5p archive to see if I can see what all the issues are...
No, I'm even more confused now :-)
> To my mind the logic goes like this:
>
> For Perl5.9.0 and later, the following two versions are equivalent:
>
> $v1 = new version 1.2.3; # that is a v-string
> $v2 = new version "1.2.3"; # that is a string
>
> and both are resolved as 1.2.3 (or 1.002003 when numified). The
> decimals are
> treated strictly as delimiters (and any leading zeros are not
> significant).
That sounds fine.
> Consequently, I believe that the following two should also be equivalent:
>
> $v3 = new version 1.2; # that is a number
> $v4 = new version "1.2"; # that is a regular string
>
> and both are resolved as 1.2 (or 1.002 when numified).
Sounds fine.
> Unfortunately, this
> conflicts with Sarathy's belief that the first should be read as
> 1.200 instead.
I'm sure this has been gone over at length, but I can't find it in p5p. Can
you point me to the appropriate thread, rather than having to recover old
ground?
Gurusamy Sarathy
>To my mind the logic goes like this:
>
>For Perl5.9.0 and later, the following two versions are equivalent:
>
> $v1 = new version 1.2.3; # that is a v-string
> $v2 = new version "1.2.3"; # that is a string
>
>and both are resolved as 1.2.3 (or 1.002003 when numified). The decimals are
>treated strictly as delimiters (and any leading zeros are not significant).
>
>Consequently, I believe that the following two should also be equivalent:
>
> $v3 = new version 1.2; # that is a number
> $v4 = new version "1.2"; # that is a regular string
>
>and both are resolved as 1.2
You mean v1.2, right?
>(or 1.002 when numified). Unfortunately, this
>conflicts with Sarathy's belief that the first should be read as 1.200 instead
>.
More accurately, I think an unadorned 1.2 should be coerced to v1.200
(the v is significant). This makes 1.23 mean v1.230, 1.234 mean v1.234,
and is consistent with 5.005 meaning v5.5, 5.005_03 meaning v5.5.30,
or 5.005_67 meaning v5.5.670.
I said the same thing in this thread:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-11/msg00448.html
> I thought I had a narrow special case that would grandfather the way that Pe
>rl
>versions were handled prior to 5.6.0, but that wasn't enough, or my arguments
>were not strong enough.
My biggest objection is the need for these special cases at all.
None are needed using the scheme above.
But then again, I haven't yet read all the discussion from over
a year ago, so I could be missing something significant. Now I'm
going to shut up again until I read that stuff. :)
Sarathy
gs...@ActiveState.com
John Peacock
> On Thu, 19 Dec 2002 10:06:19 EST, John Peacock wrote:
>
>>and both are resolved as 1.2
>
>
> You mean v1.2, right?
Yes, but probably not in the sense you mean. Version objects are not strings,
they aren't floating point numbers, and they are not v-strings. Version objects
can be initialized from any of those three types (at least with Perl 5.9.0) but
that is not what version objects are, strictly speaking. For discussion
purposes, I will start writing [1.2] (i.e. it's an array of integers separated
by periods) when I mean "version 1.2" (I can't use v1.2 since that is a
v-string, not a version).
Version objects are an ordered array of (currently) integers; each term is
evaluated independently when comparing to another version object. I say
currently, because I can see a way to support other version styles (like
Mozilla's 1.3a, 1.3rc1, etc.) as a subclass. And, no, I am not confusing the
implementation with the object; versions are best handled as an independent data
type. My definition of version objects is based on RCS Revision numbers, as
well as how a lot of open source software (other than Perl) have defined their
version numbering sequences. They would have [1.2] < [1.10] instead Perl's
historical ASCII sort order of "1.2" > "1.10".
> More accurately, I think an unadorned 1.2 should be coerced to v1.200
> (the v is significant). This makes 1.23 mean v1.230, 1.234 mean v1.234,
> and is consistent with 5.005 meaning v5.5, 5.005_03 meaning v5.5.30,
> or 5.005_67 meaning v5.5.670.
And I understand that, I just don't agree with it. ;~) To me, this will cause
more problems than it will solve, because it is not consistent. I am treating
the decimal point as merely a separator between adjascent integer values, where
you are treating it as part of a FP number. You don't have any way of
recognizing that 1.2 and 1.2.0 look almost identical, and I think it will cause
significant confusion if they are not resolved identically.
I would read version objects created using bare floating point numbers as having
implied separators every three digits after the first decimal/separator. And
this is only so that vnumify() can output something that looks like a number
from a version object.
Gurusamy Sarathy
>Gurusamy Sarathy wrote:
>> On Thu, 19 Dec 2002 10:06:19 EST, John Peacock wrote:
>>
>>>and both are resolved as 1.2
>>
>>
>> You mean v1.2, right?
>
>Yes, but probably not in the sense you mean. Version objects are not strings,
>
>they aren't floating point numbers, and they are not v-strings. Version objec
>ts
>can be initialized from any of those three types (at least with Perl 5.9.0) bu
>t
>that is not what version objects are, strictly speaking. For discussion
>purposes, I will start writing [1.2] (i.e. it's an array of integers separated
>
>by periods) when I mean "version 1.2" (I can't use v1.2 since that is a
>v-string, not a version).
>
>Version objects are an ordered array of (currently) integers; each term is
>evaluated independently when comparing to another version object. I say
>currently, because I can see a way to support other version styles (like
>Mozilla's 1.3a, 1.3rc1, etc.) as a subclass. And, no, I am not confusing the
>implementation with the object; versions are best handled as an independent da
>ta
>type. My definition of version objects is based on RCS Revision numbers, as
>well as how a lot of open source software (other than Perl) have defined their
>
>version numbering sequences. They would have [1.2] < [1.10] instead Perl's
>historical ASCII sort order of "1.2" > "1.10".
All this looks fine. I didn't much care for making a distinction
between v1.2 and [1.2] as they have the same properties in my mind.
Whether or not v1.2 produces a string of unicode characters or
something else is purely an internal detail. So whereever I've said
v1.2 (now or in the past), you may safely assume I mean [1.2].
>> More accurately, I think an unadorned 1.2 should be coerced to v1.200
>> (the v is significant). This makes 1.23 mean v1.230, 1.234 mean v1.234,
>> and is consistent with 5.005 meaning v5.5, 5.005_03 meaning v5.5.30,
>> or 5.005_67 meaning v5.5.670.
>
>And I understand that, I just don't agree with it. ;~) To me, this will cause
>more problems than it will solve, because it is not consistent. I am treating
>the decimal point as merely a separator between adjascent integer values, wher
>e
>you are treating it as part of a FP number.
I'm doing no such thing. _Perl_ treats two numbers separated by a decimal
point as an FP number. I'm merely providing a consistent way of treating
FP numbers as version numbers.
People who mean to get exactly v1.2 can always (and should be encouraged
to) write it that way. The FP conversion is purely an aid to grandfather
the older way of dealing with version numbers.
>You don't have any way of
>recognizing that 1.2 and 1.2.0 look almost identical, and I think it will caus
>e
>significant confusion if they are not resolved identically.
Assume for a moment that we outlaw writing 1.2.3 without the leading v
(i.e. make it an error, or even go back to the 5.005 interpretation
of "1.2"."3"). Would that suddenly somehow make it all consistent,
in your view? Why, or why not?
>I would read version objects created using bare floating point numbers as havi
>ng
>implied separators every three digits after the first decimal/separator.
Same as me, except for your assumption (broken in my view) that trailing
zeroes (whether they're there are not) in each triplet are not significant.
It looks like we're going around in circles again, but I just hope
that clarifies my point of view to the point where I don't have to
say anything until I've read the discussion from last year. :)
Sarathy
gs...@ActiveState.com
Andreas J. Koenig
> They would have [1.2] < [1.10] instead Perl's historical ASCII
> sort order of "1.2" > "1.10".
Maybe just nitpicking:
Perl's historical version treatment definitely never was ASCII sort.
10 was always greater than 9. In the past I've chosen to characterize
it as "strings treated as floating point numbers".
--
andreas
John Peacock
> I'm doing no such thing. _Perl_ treats two numbers separated by a decimal
> point as an FP number. I'm merely providing a consistent way of treating
> FP numbers as version numbers.
>
Just to nitpick, but the tokenizer assumes that bare numbers containing one and
only one period are FP's and are stored in an NV (cf toke.c:scan_num ) but that
doesn't mean I have to leave it that way. The tokenizer doesn't know that it
should read it any different just because it was being assigned to the special
scalar $VERSION or following the OO function call "new version".
If there was a facility to force the parameter to a function call like
version->new() to be automatically quoted (short of source filters), I would
have be able to do this long ago. To curl your hair, try and do a grep of the
current core Perl modules and see how many different kinds of $VERSION
initializations there are, not to mention doing the same with CPAN.
> People who mean to get exactly v1.2 can always (and should be encouraged
> to) write it that way. The FP conversion is purely an aid to grandfather
> the older way of dealing with version numbers.
Except for those people who are running Perl < v5.6.0. You must not think very
much of my world domination plan that all active Perl installations be able to
make use of my module. ;~(
> Assume for a moment that we outlaw writing 1.2.3 without the leading v
> (i.e. make it an error, or even go back to the 5.005 interpretation
> of "1.2"."3"). Would that suddenly somehow make it all consistent,
> in your view? Why, or why not?
Going forward with Perl v5.9.0 and greater, that's fine. In that instance, the
use of the leading 'v' has the affect of quoting the input so I can extract the
version terms. Earlier Perl's v5.6.0 - v5.8.0 (i.e. supporting v-strings but
without _magic_ v-strings), it is impossible to discern whether a v-string has
been tokenized after the fact ( v53.46.54.46.49 => "5.6.1" ).
I see this for 5.005, BTW:
$ perl5.00503 -e '$v = v5.6.1; print $v'
v56.1
so I don't know what I can do with that...
> It looks like we're going around in circles again, but I just hope
> that clarifies my point of view to the point where I don't have to
> say anything until I've read the discussion from last year. :)
Take your time. I didn't intend to renew my discussion with you until you had
read the historical documentation.
John Peacock
> Maybe just nitpicking:
Nitpicking right back at you:
>
> Perl's historical version treatment definitely never was ASCII sort.
> 10 was always greater than 9. In the past I've chosen to characterize
> it as "strings treated as floating point numbers".
>
Yes, "1.10" is greater than "1.09" if you follow the rules as given in the
Camel. This would be true whether you compared as a number or as ASCII string;
since most people seem to treat $VERSION as as string value rather than as a
number, I think of that as ASCII sorting, even though the internal testing is
[mostly] as a number. But either way, it is still true that 1.10 < 1.9 except
when using version objects [1.10] > [1.9].
You might also see the exciting macro for XS_VERSION_BOOTCHECK in XSUB.h where
strNE() is used to compare the XS_VERSION as a string. Also see the twisty
passages of universal.c:UNIVERSAL_VERSION (especially in v5.8.0) with layer upon
layer of guessing what the user really meant (string vs number vs v-string).
John Peacock
>
> It looks like we're going around in circles again, but I just hope
> that clarifies my point of view to the point where I don't have to
> say anything until I've read the discussion from last year. :)
>
I have come to the conclusion that you are right; there is no way to
sensibly handle bare numbers and quoted numbers differently. The kicker
was the number of core files which had the line:
use ExtUtils::Constant 0.11 'WriteConstants';
and yet ExtUtils::Constant used
$VERSION = '0.14';
as it's version line. Since 'use' supports _only_ bare numbers (at
least for the moment), both of those numbers _must_ be parsed in
identical fashions.
So, I have uploaded yet another release to CPAN:
version-0.26.tar.gz
has entered CPAN as
file: $CPAN/authors/id/J/JP/JPEACOCK/version-0.26.tar.gz
size: 11679 bytes
md5: b0c980be54efa27ad2332a7c2227716f
with the new code (patches to Perl itself to follow in a couple of days).
The meat of the change is that if the versions looks like a number (bare
or quoted), it will be parsed as you suggest (automatic trailing zeros
and all). If the version looks like a quoted v-string (or in 5.9.0 as a
bare v-string), it will be parsed the way I want. I have also expanded
the new() routine so that this works the way I expect:
$VERSION = new version qw$Revision: 1.23$; # this is v1.23
which should make the CVS people happy at least.
Thanks for listening and prodding me in the correct direction...
John
Gurusamy Sarathy
>I have come to the conclusion that you are right; there is no way to
>sensibly handle bare numbers and quoted numbers differently. The kicker
>was the number of core files which had the line:
>
> use ExtUtils::Constant 0.11 'WriteConstants';
>
>and yet ExtUtils::Constant used
>
> $VERSION = '0.14';
>
>as it's version line. Since 'use' supports _only_ bare numbers (at
>least for the moment), both of those numbers _must_ be parsed in
>identical fashions.
>
>So, I have uploaded yet another release to CPAN:
>
> version-0.26.tar.gz
>
>has entered CPAN as
>
> file: $CPAN/authors/id/J/JP/JPEACOCK/version-0.26.tar.gz
> size: 11679 bytes
> md5: b0c980be54efa27ad2332a7c2227716f
>
>with the new code (patches to Perl itself to follow in a couple of days).
Sounds good. For the record, I didn't do anything here except play
the dangerously uninformed sceptic. The hard work was all yours. :)
Thanks,
Sarathy
gs...@ActiveState.com