RFC: version.pm qv() confusion

[John Peacock <john.peacock@havurah-software.org>]

More than a couple of module authors have confused qv() with 
version->new() as the generic method of creating version objects [1]. 
I'm going to try and rewrite the version.pm POD to emphasize this point 
again, but the horse is already out of the stable, down the hill and 
caught in a bog. :(

A discussion has recently broken out about Strawberry Perl and CPANPLUS 
which essentially boiled down to not having a current enough 
Module::Load::Conditional (which was one of the modules that use qv() 
erroneously at one point) present in the Strawberry Perl release.

I can't deprecate qv() (much as I'd like to) because it is included with 
Perl 5.10.0's implementation of version.pm, but I can add a new helper 
function to assist authors who think

	version->new()

is too much to type. ;-)

The problem is, I don't know what to call it?  None of the following are 
ideal:

	nv()
	vv()
	newv()

Anyone what to venture an opinion?

John

1) the issue is that qv() forces the extended (i.e. multiple decimal) 
version notation, _even_ when passed a nominally floating point 
initializer.  It was intended to be used in Perl's < 5.8.1 to simulate 
magic v-string's, but I wish I'd never included it.  In other words:

qv('1.2') == qv('v1.2') == qv('1.2.0') == version->new('1.2.0')== v1.2.0

---

Follow-Ups from:

Gisle Aas <gisle@activestate.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---