Restatement of current objections to version objects
John Peacock
objections to version objects. I don't claim that this is a complete list, nor
do I pretend that these are the only objections, nor that I am doing any justice
to the original complaints. I just want to connect the different threads
together again (so I don't have so many different threads active). I'll try and
credit the objectors, but again, I may miss someone.
----
1) Basic nature of v-strings has changed (embedded zeros/underscores)
[Andreas/Graham/Benjamin]
Patch #13028, which extracted the v-stringification code from toke.c and made it
a separate function in util.c changed two other things at the same time. It
eliminated the prohibition on leading 0's in subsequences of v-strings and it
changed the handling of underscores in v-strings (since retracted).
As bleadperl stands now, the only difference between v-string behavior pre-5.8
and now is the elimination of the prohibition on leading 0's. The
implementation is completely different (in that v-strings are now a form of
magic), but the behavior is otherwise identical.
I argue that this limitation is not useful, since v-strings are not integers,
hence the leading-zero-means-octal is not an appropriate application. It also
precludes the use of any version that might be unquoted in the source that has
leading zeros. My highest goal is to take [virtually] any existing module and
have it work without change.
----
2) Beta version notation alters grammer of v-strings [Andreas/Benjamin/Graham]
My proposed handling of beta versions gives meaning to underscores in v-strings
that does not exist otherwise. My argument is, and has been all along, that the
discussion in perl56delta.pod leads to no other conclusion. For Perl versions:
5.005_03 == 5.5.30
so the choice has to be made to special case Perl versions alone or to use the
same notation to specify beta versions of ordinary modules. As an additional
argument for my suggestion is this discussion taken from the pod for the CPAN
module:
> Developers may mark their releases as unstable development versions (by inserting an underbar into the module version number which will also be reflected in the distribution name when you run 'make dist')...
No special handling needs to be done for this to work with my code in place.
The suggestion was made the the even/odd subversion distinction be made for beta
releases in ordinary modules (much like Perl or Linux distros use), but that
would have the drawback that lots of ordinary modules on CPAN may already have
an odd subversion and yet be the stable release. I also think it is much too
late to change the notation, since the CPAN style has been in use for a
significant length of time (and the CPAN module itself would need surgery in
order to enforce the even/odd notation).
----
Anything else? I've already eliminated the objection to the stringified output
having leading zeros (since I don't need it any longer).
----
CONCLUDING REMARKS
As another way to think about this, how about if we state that version numbers
are implicitly quoted when keyed as bare numbers _or_ v-strings, since this is
literally what happens with my changes.
$VERSION = new version 1.2;
$VERSION = new version v1.2;
$VERSION = new version "1.2";
all yield a version which is stored as \1\2 and outputs as 1.2. The only caveat
is that this is not [currently] possible with floating-point numbers containing
underscores (since the tokenizer already skips the underscores). I can special
case code of the form:
require 5.005_03;
since the tokenizer already has a seperate path for that (force_version) which
can be bent to my will. In any case, existing beta version on CPAN use a quoted
form for their $VERSION (to preserve the underscore), so this is probably not
much of a limitation.
Going forward, the $VERSION scalar itself will become magical and autoquote the
assigned value as part of upgrading it to a version object, so this will also be
true:
$VERSION = 1.2;
$VERSION = v1.2;
$VERSION = "1.2";
and the version object will be identical to the one listed above.
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
Horsley Tom
output
> having leading zeros (since I don't need it any longer).
Your forgot a more fundamental one:
The valuable contributions that vstrings make to the language
require an electron microscope to observe, yet the effort
required to implement them could have built a new Mt. Rushmore
monument :-).
(Of course, if people actually enjoy working on vstrings,
who am I to object?, but it all seems really really pointless).
Andreas J. Koenig
John, I'm about to change my mind. I'll soon give up my objections.
Just let me ask one more question to see more of your thinking...
> CONCLUDING REMARKS
> As another way to think about this, how about if we state that version
> numbers are implicitly quoted when keyed as bare numbers _or_
> v-strings, since this is literally what happens with my changes.
> $VERSION = new version 1.2;
> $VERSION = new version v1.2;
> $VERSION = new version "1.2";
Can you elaborate how that shall work for 1.02, 1.002 and v1.02?
All equal? 1.002 v1.2 v1.02 v1.002 ... "1.2" "1.02" "1.002"
All equal? 1.02 v1.20 v1.020 v1.0020 ... "1.20" "1.020" "1.0020"
--
andreas
John Peacock
>>>>>>On Mon, 02 Sep 2002 10:26:50 -0400, John Peacock <jpea...@rowman.com> said:
>>>>>
>
> John, I'm about to change my mind. I'll soon give up my objections.
> Just let me ask one more question to see more of your thinking...
>
> > CONCLUDING REMARKS
>
> > As another way to think about this, how about if we state that version
> > numbers are implicitly quoted when keyed as bare numbers _or_
> > v-strings, since this is literally what happens with my changes.
>
> > $VERSION = new version 1.2;
> > $VERSION = new version v1.2;
> > $VERSION = new version "1.2";
>
> Can you elaborate how that shall work for 1.02, 1.002 and v1.02?
>
> All equal? 1.002 v1.2 v1.02 v1.002 ... "1.2" "1.02" "1.002"
1.2 1.2 1.2 1.2
>
> All equal? 1.02 v1.20 v1.020 v1.0020 ... "1.20" "1.020" "1.0020"
>
1.2 1.20 1.20 1.20
>
>
The Perl-style version code is strictly limited to cover the 5.005_03 kind of case:
....
if (*d == '_') {
*d = '.';
if (*(d+1) == '0' && *(d+2) != '0') { /* perl-style version */
....
so it fires iff an underscore is followed by a single zero with another non-zero
digit following that. Everything else is translated as if each subversion were
an independant integral value (ignoring leading but not trailing zeros).
Andreas J. Koenig
> Andreas J. Koenig wrote:
>>>>>>> On Mon, 02 Sep 2002 10:26:50 -0400, John Peacock <jpea...@rowman.com> said:
>>>>>>
>> John, I'm about to change my mind. I'll soon give up my objections.
>> Just let me ask one more question to see more of your thinking...
>> > CONCLUDING REMARKS
>> > As another way to think about this, how about if we state that
>> version
>> > numbers are implicitly quoted when keyed as bare numbers _or_
>> > v-strings, since this is literally what happens with my changes.
>> > $VERSION = new version 1.2;
>> > $VERSION = new version v1.2;
>> > $VERSION = new version "1.2";
>> Can you elaborate how that shall work for 1.02, 1.002 and v1.02?
>> All equal? 1.002 v1.2 v1.02 v1.002 ... "1.2" "1.02" "1.002"
> 1.2 1.2 1.2 1.2
>> All equal? 1.02 v1.20 v1.020 v1.0020 ... "1.20" "1.020"
>> "1.0020"
>>
> 1.2 1.20 1.20 1.20
Thanks! I think I start to understand where you intend to go. Sorry it
took me so long.
> The Perl-style version code is strictly limited to cover the 5.005_03 kind of case:
> ...
> if (*d == '_') {
> *d = '.';
> if (*(d+1) == '0' && *(d+2) != '0') { /* perl-style version */
> ...
> so it fires iff an underscore is followed by a single zero with
> another non-zero digit following that.
This is your plan, I suppose, not yet reality, right?
Can you make sure that these continue to work:
% /usr/local/perl-5.8.0@17822/bin/perl -le 'require 5.00556'
% /usr/local/perl-5.8.0@17822/bin/perl -le 'require 5.00602'
% /usr/local/perl-5.8.0@17822/bin/perl -le 'require 5.00702'
?
--
andreas
John Peacock
> > The Perl-style version code is strictly limited to cover the 5.005_03 kind of case:
> > ...
> > if (*d == '_') {
> > *d = '.';
> > if (*(d+1) == '0' && *(d+2) != '0') { /* perl-style version */
> > ...
>
> > so it fires iff an underscore is followed by a single zero with
> > another non-zero digit following that.
>
> This is your plan, I suppose, not yet reality, right?
The code that does this is in bleadperl, but the hooks to make use/require
actually do something with it is still only on my hard-drive. I am waiting
until the version object input/output has been hammered out before submitting
anything else. The coming patches make Perl:
a) use a version object for PL_patchlevel (i.e. $] and $^V)
b) simplify UNIVERSAL::VERSION (by using version objects for all comparisons)
c) make force_version() autoupgrade to version objects
d) make XS_VERSION_BOOTCHECK use version objects for comparison
a & b are completed and tested. c is mostly completed but I need to do more
testing (as well as deal with your examples below). d is currently where I am
stuck, since this is a macro and I am somehow triggering a segfault and it is
not easy to see what is going wrong. I may just have to rewrite that code from
scratch so I know what is going on...
>
> Can you make sure that these continue to work:
>
> % /usr/local/perl-5.8.0@17822/bin/perl -le 'require 5.00556'
> % /usr/local/perl-5.8.0@17822/bin/perl -le 'require 5.00602'
> % /usr/local/perl-5.8.0@17822/bin/perl -le 'require 5.00702'
>
I haven't dealt with this yet; I hope I can limit this to the use/require code,
because I don't want to have to assume '3 decimal places per subversion' for all
code, just the Perl-version aware portion. In theory it isn't too hard...
Yitzchak Scott-Thoennes
John isn't working "on vstrings", precisely. He is just trying to get
version comparison working everywhere. If anything, vstrings make his
job harder since they are a third way to specify a version.
Think of vstrings as the dog leading the (wrong) way, and John
desperately following with the leash, the scoop, and the bag.
John Peacock
> John isn't working "on vstrings", precisely. He is just trying to get
> version comparison working everywhere. If anything, vstrings make his
> job harder since they are a third way to specify a version.
>
> Think of vstrings as the dog leading the (wrong) way, and John
> desperately following with the leash, the scoop, and the bag.
I think it's more like v-strings are like cats (and we all know how easy it is
to herd cats ;~), except I have now "belled the cat" by making all v-strings
identifiable as such.
h...@crypt.org
:> Anything else? I've already eliminated the objection to the stringified
:output
:> having leading zeros (since I don't need it any longer).
:
:Your forgot a more fundamental one:
:
:The valuable contributions that vstrings make to the language
:require an electron microscope to observe, yet the effort
:required to implement them could have built a new Mt. Rushmore
:monument :-).
Larry continues to like them despite various attempts to convince
him otherwise, so they are here to stay. I think they could become
much less of a bugbear if John's sterling work culminates in a
consistent and appropriately documented set of behaviours.
Hugo