Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

UNIVERSAL::VERSION and version.pm

 

 

Perl porters RSS feed   Index | Next | Previous | View Threaded


john.peacock at havurah-software

Oct 6, 2008, 5:06 AM

Post #1 of 22 (6277 views)
Permalink
UNIVERSAL::VERSION and version.pm

Let me make something perfectly clear: I am not changing the external interface
of the CPAN release version.pm for *any* reason. I am not having the arguments
all over again. Here's why: version.pm is now in the Perl core with 5.10.0.
The exact same code in the XS version of the CPAN release is in Perl itself.
This goes for the UNIVERSAL::VERSION code as well. So the CPAN release's only
reason for living is the allow people to 'use version' in any release of Perl
from 5.005_04 onwards and have it work exactly[1] the same way for every release
of Perl.

The problem has always been that module authors have never understood $VERSION.
Before version.pm, it was *always* evaluated as a floating point number:

1.10 < 1.9

and that's that. The documentation always said to use two place decimals for
precisely this reason (see /Programming Perl/ Chapter 7). PAUSE has always
protected you, as a module author, from doing something stupid like the above.
Recently (as in two years ago?), Andreas has added the ability of authors to
"reset" their latest release, something that should not be done lightly.

The other thing that has never been clear to the vast majority of Perl users,
let alone module authors, is that this:

use module 1.2;

is magical. If and only if the first thing after the module name looks like a
number, which means the equivalent of /\d+(\.\d*)?/, then Perl itself will use
UNIVERSAL::VERSION to determine whether the module on disk meets that minimal
version. Anything else, like a quoted number, is assumed to be a parameter to
be passed to the module's import() routine. That's been there since the dawn of
time (AFAICT before 5.000).

However, while Perl was happily consistent about using numeric versions, the
rest of the open source community moved towards using MAJOR.MINOR.PATCH
multi-level versioning (aided and abetted by CVS's fsked-up $Revision$ string).
Thus was born the v-string in Perl 5.6.0, which was intended to be a way to
encode a multipart $VERSION into a simple scalar. It failed in that respect
(because it was too simple).

So, I spent a couple of years (no joke) trying to make v-strings work, but
failed (other than making v-strings be a magic variable rather than a simple
tokenizer hack). And then I spent several more years writing and perfecting
version.pm so that it Does The Right Thing in the purest Perl sense. But the
use of it by module authors does require reading the damn POD! Based on the
voluminous feedback on P5P, I added this paragraph right up front (after the
DESCRIPTION):

BEST PRACTICES

If you intend for your module to be used by different releases of Perl,
and/or for your $VERSION scalar to mean what you think it means, there
are a few simple rules to follow:

* Be consistent
Whichever of the two types of version objects that you choose to
employ, you should stick to either "Numeric Versions" or "Extended
Versions" and not mix them together. While this is possible, it is
very confusing to the average user.

In the case of Parse::RecDescent, Damian chose to ignore this advice, which is
what ultimately sparked the rant on we-hates-software.

I suppose I should write a page for PAUSE that explains what will happen if you
switch from numeric to extended versions (since it already scans for that). I'm
pretty sure that Andreas would put it up. The short answer is that, as an
author, if you have already released 1.94 to CPAN, you should either stick with
numeric versions (1.95, 1.96, etc) or if you really want to switch to an
extended version, go straight to v2.0.0. However, if you are starting from
scratch, you can use the qv() operator to DTRT for you, even if you don't use
multiple decimals:

1.10 < 1.9
qv('1.10') > qv('1.9') i.e. 1.10.0 > 1.9.0

qv() forces an extended version interpretation, even if there is only a single
decimal place. In hindsight, I wish I had never added that method, since it has
only served to confuse and irritate authors, who don't read the POD and assumes
it is a drop-in replacement for version->new().

In conclusion, every single idea discussed in the former thread has already been
discussed, /ad naseum/, in public on P5P over the last 8 years. I'm not willing
to reopen negotiations and in fact, given that the code is now inside Perl
itself, I cannot.

<TRON>END OF LINE</TRON>

John

1) Perl 5.005 cannot handle v-strings at all, so you have to quote the value for
new() or qv(). Perl 5.6.0 has v-strings, but the original representation
vanishes during tokenizing and version.pm has a heuristic that tries to guess
whether you meant to say 1.2.3 or not. It is still highly recommended to quote
your values, because then everyone is happy


gbarr at pobox

Oct 6, 2008, 6:05 AM

Post #2 of 22 (6186 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

On Oct 6, 2008, at 7:06 AM, John Peacock wrote:
> The other thing that has never been clear to the vast majority of
> Perl users,
> let alone module authors, is that this:
>
> use module 1.2;
>
> is magical. If and only if the first thing after the module name
> looks like a
> number, which means the equivalent of /\d+(\.\d*)?/, then Perl
> itself will use
> UNIVERSAL::VERSION to determine whether the module on disk meets
> that minimal
> version. Anything else, like a quoted number, is assumed to be a
> parameter to
> be passed to the module's import() routine. That's been there since
> the dawn of
> time (AFAICT before 5.000).

No, I implemented it in the late '90s. Prior to that the only way to
require a specific
version of a module was if that module inherited from Exporter,
because Exporter did
the same treatment to its first argument.

Graham.


matt-p5p at trout

Oct 7, 2008, 10:01 AM

Post #3 of 22 (6172 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

On Mon, Oct 06, 2008 at 08:06:00AM -0400, John Peacock wrote:
> Let me make something perfectly clear: I am not changing the external interface
> of the CPAN release version.pm for *any* reason.

That's not what I want anyway, and frankly I agree entirely that any change
to the behaviour of "use version" at this point would be Bad And Wrong.

I just want to be able to do

use version::comparison;

and get the ability to do qv(), to make version objects, and to compare them,
without having UNIVERSAL::VERSION overwritten, in the case where that's
what I feel is better for the program at hand.

I would also like to be able to do (but consider it less important)

use version::comparison qw(VERSION);

to install a *VERSION into -my- package so that MyPackage->VERSION returns
a 5.10-compatible version object, without affecting the interpreter behaviour
globally.

Neither of these would change the external interface of version.pm itself
at all - they'd just allow those of us who only want a subset of that
interface access to that subset. TMTOWTDI and all that.

I also have no expectation that you would do any of the work to achieve
this except for applying patches and shipping a tarball.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/


john.peacock at havurah-software

Oct 7, 2008, 5:33 PM

Post #4 of 22 (6167 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

Matt S Trout wrote:
> I just want to be able to do
>
> use version::comparison;
>
> and get the ability to do qv(), to make version objects, and to compare them,
> without having UNIVERSAL::VERSION overwritten, in the case where that's
> what I feel is better for the program at hand.
>
> I would also like to be able to do (but consider it less important)
>
> use version::comparison qw(VERSION);
>
> to install a *VERSION into -my- package so that MyPackage->VERSION returns
> a 5.10-compatible version object, without affecting the interpreter behaviour
> globally.

It's trivially easy to subclass version.pm to bend it to your will:

$ cat lib/version/comparison.pm
package version::comparison;
BEGIN {
$UNIVERSAL_VERSION = \&UNIVERSAL::VERSION;
}
use parent qw/version/;
$NEW_UNIVERSAL_VERSION = \&UNIVERSAL::VERSION;
*UNIVERSAL::VERSION = \&{$UNIVERSAL_VERSION};

sub import {
my ($class, $option) = @_;
my $callpkg = caller();
no strict 'refs';
if (defined($option) and $option eq 'VERSION') {
*{$callpkg."::VERSION"} = \&{$NEW_UNIVERSAL_VERSION};
}
*{$callpkg."::qv"} =
sub {return bless version::qv(shift), $class }
unless defined(&{"$callpkg\::qv"});
}
1;

John


matt-p5p at trout

Oct 8, 2008, 5:11 AM

Post #5 of 22 (6170 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

On Tue, Oct 07, 2008 at 08:33:15PM -0400, John Peacock wrote:
> Matt S Trout wrote:
> > I just want to be able to do
> >
> > use version::comparison;
> >
> > and get the ability to do qv(), to make version objects, and to compare them,
> > without having UNIVERSAL::VERSION overwritten, in the case where that's
> > what I feel is better for the program at hand.
> >
> > I would also like to be able to do (but consider it less important)
> >
> > use version::comparison qw(VERSION);
> >
> > to install a *VERSION into -my- package so that MyPackage->VERSION returns
> > a 5.10-compatible version object, without affecting the interpreter behaviour
> > globally.
>
> It's trivially easy to subclass version.pm to bend it to your will:

I know. But that's kind of a hack.

I was hoping I could get patches into CPAN version.pm to achieve the same
thing without needing to pull such a hack.

I don't really understand why you're happy to type out a complete hack into
email but won't even give tentative agreement to us writing you a simple
patch that would obviate the need to it?

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/


john.peacock at havurah-software

Oct 8, 2008, 5:58 AM

Post #6 of 22 (6174 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

Matt S Trout wrote:
> I don't really understand why you're happy to type out a complete hack into
> email but won't even give tentative agreement to us writing you a simple
> patch that would obviate the need to it?

Perhaps because I have some intimation exactly how hard it is going be
to do in the core code? It's easy in the pure Perl implementation,
since you can simply delay loading the UNIVERSAL::VERSION until
import(), but the XS code doesn't work like that. Trying to do both
modes in the same way is somewhat tricky and something I really don't
even have time to think about right now.

I'm not even sure there's a compelling reason to put it in the core code
anyways. I could just release the "complete hack" as its own package on
CPAN...

John


matt-p5p at trout

Oct 8, 2008, 8:29 AM

Post #7 of 22 (6167 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

On Wed, Oct 08, 2008 at 08:58:52AM -0400, John Peacock wrote:
> Matt S Trout wrote:
> >I don't really understand why you're happy to type out a complete hack into
> >email but won't even give tentative agreement to us writing you a simple
> >patch that would obviate the need to it?
>
> Perhaps because I have some intimation exactly how hard it is going be
> to do in the core code?

Given I'm only asking you to express willingness to -apply- such a patch
if it were successfully written, how exactly is that relevant?

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/


matt-p5p at trout

Oct 8, 2008, 8:40 AM

Post #8 of 22 (6169 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

On Wed, Oct 08, 2008 at 08:58:52AM -0400, John Peacock wrote:
> Matt S Trout wrote:
> >I don't really understand why you're happy to type out a complete hack into
> >email but won't even give tentative agreement to us writing you a simple
> >patch that would obviate the need to it?
>
> Perhaps because I have some intimation exactly how hard it is going be
> to do in the core code? It's easy in the pure Perl implementation,
> since you can simply delay loading the UNIVERSAL::VERSION until
> import(), but the XS code doesn't work like that. Trying to do both
> modes in the same way is somewhat tricky and something I really don't
> even have time to think about right now.

Let me rephrase my previous email.

The key part of my previous post was "us writing you a simple patch". The
fact that it might turn out not to be simple doesn't obviate the bit where
"us", i.e. -not- "you", would be writing said patch.

I understand that people can be busy and since this is something I care about
and you don't I have no right to expect you to even think about how to
implement it.

But before I, or anybody else, puts time into working out if it's possible
to implement it and if possible if it's worth the effort, and if so actually
tries to implement the damn thing, we'd like to know that if we -do- manage
to produce a working patch it would likely be accepted.

That's all I'm asking for.

If somebody else does the work, would you be willing to incorporate the patch
into the module?

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/


john.peacock at havurah-software

Oct 9, 2008, 5:40 AM

Post #9 of 22 (6154 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

Matt S Trout wrote:
> If somebody else does the work, would you be willing to incorporate the patch
> into the module?

Let me make a counter proposal:

use version;
# current behavior, exports qv() to caller and overwrites UNIVERSAL::VERSION

use version ();
# exports nothing and doesn't override UNIVERSAL::VERSION

use version qw/qv/;
# exports only qv to caller

use version qw/VERSION/;
# exports only replacement UNIVERSAL::VERSION in callers namespace

After your last message, I saw how I could do this and still preserve the
existing interface. I actually have a patch, though I want to write more tests
before I release it.

Satisfied??? ;-)

John


rgiersig at cpan

Oct 9, 2008, 6:07 AM

Post #10 of 22 (6151 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

John Peacock wrote:
> Satisfied??? ;-)

*applaudsfromthesideline*

Thanks for resolving this in such a civilised way. For a brief moment
you had us worrying... :-)

I'd buy you both a beer (and will do if we shall meet in the future).

Cheers! Roland


matt-p5p at trout

Oct 10, 2008, 12:05 AM

Post #11 of 22 (6155 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

On Thu, Oct 09, 2008 at 08:40:28AM -0400, John Peacock wrote:
> Matt S Trout wrote:
> > If somebody else does the work, would you be willing to incorporate the patch
> > into the module?
>
> Let me make a counter proposal:
>
> use version;
> # current behavior, exports qv() to caller and overwrites UNIVERSAL::VERSION
>
> use version ();
> # exports nothing and doesn't override UNIVERSAL::VERSION
>
> use version qw/qv/;
> # exports only qv to caller
>
> use version qw/VERSION/;
> # exports only replacement UNIVERSAL::VERSION in callers namespace
>
> After your last message, I saw how I could do this and still preserve the
> existing interface. I actually have a patch, though I want to write more tests
> before I release it.

That's fucking awesome. Anything I can do to help?

> Satisfied??? ;-)

Hell yeah. Claim a beer off me next conference we're both at.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/


john.peacock at havurah-software

Oct 11, 2008, 7:18 AM

Post #12 of 22 (6162 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

Matt S Trout wrote:
> That's fucking awesome. Anything I can do to help?

Yeah, you can tell me how you plan on using this mode:

use version qw/VERSION/;
# exports only replacement UNIVERSAL::VERSION in caller's namespace

because I can't see any reason to use it at all. Here's what the core
UNIVERSAL::VERSION does (my replacement's behavior in square brackets):

1) takes either a class or an object of a class
2) if that class isn't loaded, loads it
3) grabs the $CLASS::VERSION scalar
4) compares against the requested version [in a version-object way]
5) croaks if $CLASS::VERSION < $requested
6) returns [a stringified representation of] $CLASS::VERSION

I can't see any reason to use that in any code outside of the core. Care to
enlighten me?

In particular, the need to wrap any usage of this code inside an eval strongly
limits it use. If you just want to use the version comparison code, use qv() or
version->new() and then make use of the overloaded comparisons with any other
$VERSION scalar.

John


matt-p5p at trout

Oct 11, 2008, 8:10 AM

Post #13 of 22 (6140 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

On Sat, Oct 11, 2008 at 10:18:28AM -0400, John Peacock wrote:
> Matt S Trout wrote:
> > That's fucking awesome. Anything I can do to help?
>
> Yeah, you can tell me how you plan on using this mode:
>
> use version qw/VERSION/;
> # exports only replacement UNIVERSAL::VERSION in caller's namespace
>
> I can't see any reason to use that in any code outside of the core. Care to
> enlighten me?

Using

$VERSION = qv('1.2.3');

and having core things still be happy springs to mind.

Plus I've often seen code that does $class->VERSION and I'd be willing to bet
there's some somewhere that won't handle getting a version object back.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/


pagaltzis at gmx

Oct 11, 2008, 8:33 AM

Post #14 of 22 (6142 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

* Matt S Trout <matt-p5p [at] trout> [2008-10-11 17:15]:
> Plus I've often seen code that does $class->VERSION and I'd be
> willing to bet there's some somewhere that won't handle getting
> a version object back.

Question is though, how many of these places will DTRT with the
stringified version? If a version object breaks the code most of
the time and a stringified version DTWT some of the time, all you
can do is pick your kind of breakage, and frankly I’d prefer the
bigger and more reproducible breakage in that case. The real
solution in that case is to fix the code that can’t handle
getting a version object.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>


schwern at pobox

Oct 11, 2008, 6:37 PM

Post #15 of 22 (6146 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

Matt S Trout wrote:
> Plus I've often seen code that does $class->VERSION and I'd be willing to bet
> there's some somewhere that won't handle getting a version object back.

I'm having a real hard time coming up with a plausible scenario. This is just
the sort of thing operator overloading was designed for.


--
164. There is no such thing as a were-virgin.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/


john.peacock at havurah-software

Oct 12, 2008, 3:50 AM

Post #16 of 22 (6124 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

Michael G Schwern wrote:
> Matt S Trout wrote:
>> Plus I've often seen code that does $class->VERSION and I'd be willing to bet
>> there's some somewhere that won't handle getting a version object back.
>
> I'm having a real hard time coming up with a plausible scenario. This is just
> the sort of thing operator overloading was designed for.

As a matter of fact, $class->VERSION always returns the stringified version
object, not a version object, so this is yet another FUD. I've got a longer
e-mail I'm working on...

John


john.peacock at havurah-software

Oct 12, 2008, 4:47 AM

Post #17 of 22 (6127 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

Matt S Trout wrote:
> Using
>
> $VERSION = qv('1.2.3');
>
> and having core things still be happy springs to mind.

I don't understand how having the UNIVERSAL::VERSION method in *your* module's
namespace as &VERSION has anything to do with that. In fact, if *any* module
you are using (directly or indirectly) has extended versions (multiple
decimals), you *are* going to break something if you don't have the object-aware
UNIVERSAL::VERSION loaded globally.

> Plus I've often seen code that does $class->VERSION and I'd be willing to bet
> there's some somewhere that won't handle getting a version object back.

The replacement UNIVERSAL::VERSION returns the stringified representation of
$class::VERSION in all cases, _never_ a version object (I was coerced into
making that change by arguments on P5P, in fact). It only uses version objects
internally to perform a comparison, and that iff you give it a minimum version.
The only time you could potentially get a version object back is using
$class::VERSION. And since version objects are fully overloaded, I can't even
think of a way that could be a problem for ordinary code anyways (this was
Schwern's point too).

I think that there is still some confusion about the nature of
UNIVERSAL::VERSION and what it does.

This mode (with modern Perl's):

use Module 1.2;

finds and loads "Module", then calls UNIVERSAL::VERSION implicitly with the
terms "Module" and 1.2 which throws a variety of fatal errors depending on what
Module has in the Module::VERSION scalar. With older Perl's, this was also the
mode of operation for any Module that inherited from Exporter (thanks for
clearing that up Graham).

This mode (with ancient or modern Perl's):

$class_version = $class->VERSION(1.2);

would throw errors if $class didn't have a $class::VERSION scalar that was
numerically greater than 1.2, and as a side effect return the contents of the
$class::VERSION scalar. The replacement &UNIVERSAL::VERSION does this too, but
groks extended version notation too.

This mode (again everywhere):

$class_version = $class->VERSION;

returns the $class::VERSION scalar (or undef if one doesn't exists), i.e. just
the side effect of the preceding example. In most cases, this is precisely the
same thing as referencing the scalar directly $class::VERSION. The one time
this will be differt is if $class is using a version object; then
$class::VERSION will return the object and $class->VERSION will returned the
stringified object.

I'm sorry, Matt, but the more you argue that you need to not replace
UNIVERSAL::VERSION, the more you are convincing me you are doing it from some
(IMVHO) misguided "purity" standpoint and not because of actual or even
theoretical harm. I can guarantee that causing UNIVERSAL::VERSION to not be
overridden by the version-object aware replacement *will* cause problems with
currently working code. On the other hand, I have yet to be shown _any_ code
that will break with the replacement code in place.

I am willing to be convinced, but I'm not going to change version.pm based
solely on Fear, Uncertainty, and Doubt.

John


matt-p5p at trout

Nov 12, 2008, 11:28 AM

Post #18 of 22 (5930 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

On Sun, Oct 12, 2008 at 07:47:55AM -0400, John Peacock wrote:
> I'm sorry, Matt, but the more you argue that you need to not replace
> UNIVERSAL::VERSION, the more you are convincing me you are doing it from some
> (IMVHO) misguided "purity" standpoint and not because of actual or even
> theoretical harm. I can guarantee that causing UNIVERSAL::VERSION to not be
> overridden by the version-object aware replacement *will* cause problems with
> currently working code. On the other hand, I have yet to be shown _any_ code
> that will break with the replacement code in place.
>
> I am willing to be convinced, but I'm not going to change version.pm based
> solely on Fear, Uncertainty, and Doubt.

I wish I had a failing test for you, but it appears that the code in
question only existed in the repository of a now-defunct client of Shadowcat's.

It's entirely possible that version.pm no longer has the bug that caused
that - but unless there is a way to mathematically prove that it no longer
contains -any- bugs, we can't be sure that it's safe.

I do have to ask though - if this change to UNIVERSAL::VERSION's behaviour
is so simple and safe ... why isn't it in 5.8.9?

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/


john.peacock at havurah-software

Nov 12, 2008, 6:27 PM

Post #19 of 22 (5917 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

Matt S Trout wrote:
> It's entirely possible that version.pm no longer has the bug that caused
> that - but unless there is a way to mathematically prove that it no longer
> contains -any- bugs, we can't be sure that it's safe.

That's kind of a silly statement to make; Perl is not a mathematical
system that can be used to generate proofs like that. Additionally, it
is impossible to prove a negative assertion.

> I do have to ask though - if this change to UNIVERSAL::VERSION's behaviour
> is so simple and safe ... why isn't it in 5.8.9?

Because Perl 5.8.x is not where new features can be introduced; it is
intended to be stable (bugfixes only). As much as I'd like to say so,
Perl's $VERSION handling is not a bug...

John


schwern at pobox

Nov 12, 2008, 6:53 PM

Post #20 of 22 (5924 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

Matt S Trout wrote:
> On Sun, Oct 12, 2008 at 07:47:55AM -0400, John Peacock wrote:
>> I'm sorry, Matt, but the more you argue that you need to not replace
>> UNIVERSAL::VERSION, the more you are convincing me you are doing it from some
>> (IMVHO) misguided "purity" standpoint and not because of actual or even
>> theoretical harm. I can guarantee that causing UNIVERSAL::VERSION to not be
>> overridden by the version-object aware replacement *will* cause problems with
>> currently working code. On the other hand, I have yet to be shown _any_ code
>> that will break with the replacement code in place.
>>
>> I am willing to be convinced, but I'm not going to change version.pm based
>> solely on Fear, Uncertainty, and Doubt.
>
> I wish I had a failing test for you, but it appears that the code in
> question only existed in the repository of a now-defunct client of Shadowcat's.
>
> It's entirely possible that version.pm no longer has the bug that caused
> that - but unless there is a way to mathematically prove that it no longer
> contains -any- bugs, we can't be sure that it's safe.

mst has been possessed by the future ghost of Donald Knuth.


> I do have to ask though - if this change to UNIVERSAL::VERSION's behaviour
> is so simple and safe ... why isn't it in 5.8.9?

Because none of the 5.8 core modules need version.pm, and 5.8.9 is a bug fix
release.


--
'All anyone gets in a mirror is themselves,' she said. 'But what you
gets in a good gumbo is everything.'
-- "Witches Abroad" by Terry Prachett


matt-p5p at trout

Dec 3, 2008, 1:56 PM

Post #21 of 22 (5850 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

On Wed, Nov 12, 2008 at 09:27:23PM -0500, John Peacock wrote:
> Matt S Trout wrote:
> > It's entirely possible that version.pm no longer has the bug that caused
> > that - but unless there is a way to mathematically prove that it no longer
> > contains -any- bugs, we can't be sure that it's safe.
>
> That's kind of a silly statement to make; Perl is not a mathematical
> system that can be used to generate proofs like that. Additionally, it
> is impossible to prove a negative assertion.

Of course. Please also solve the Halting Problem :)

> > I do have to ask though - if this change to UNIVERSAL::VERSION's behaviour
> > is so simple and safe ... why isn't it in 5.8.9?
>
> Because Perl 5.8.x is not where new features can be introduced; it is
> intended to be stable (bugfixes only). As much as I'd like to say so,
> Perl's $VERSION handling is not a bug...

Which is why I think it would be nice to be able to have part of the features
of your version comparison library be optional :)

In large codebases, I might want the version object information, but follow
"if it ain't broke don't fix it" in terms of UNIVERSAL:: things.

Projects where you can't just test the damn thing and see if it breaks anything
do, sadly, exist :)

What you're basically saying is "if you want my version library, you must also
let me make an action-at-a-distance change to your interpreter". I am aware
that action at a distance -can- be good, but unless I know I need it I'd still
prefer to avoid it.

Basically, there's more than one way to do it - all I'm asking is that your
module allows mine as well, with yours by default, rather than enforcing yours.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/


john.peacock at havurah-software

Dec 3, 2008, 5:50 PM

Post #22 of 22 (5857 views)
Permalink
Re: UNIVERSAL::VERSION and version.pm [In reply to]

Matt S Trout wrote:
> What you're basically saying is "if you want my version library, you must also
> let me make an action-at-a-distance change to your interpreter". I am aware
> that action at a distance -can- be good, but unless I know I need it I'd still
> prefer to avoid it.

No, I'm saying that if I do as you ask, there will be an even bigger
action-at-a-distance bug, where the behavior of version comparisons will
depend on whether your code gets loaded before or after some other
module loads version.pm. That's a worse problem.

I've given you plenty of rope to hang yourself with already, I don't
intend to make it worse...

John

Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.