From @jkeenan

In a perl5-porters list discussion beginning here​:

http​://markmail.org/search/?q=perl5-porters#query​:perl5-porters%20order%3Adate-backward+page​:2+mid​:yzcyfzizqig6vmoy+state​:results

Ricardo Signes wrote​:

#####
A few times lately, $^V has come up in the context of being "the better way to check the version than $]." This surprised me, because I always thought it was largely considered better avoided.

I suggest that given the general confusion around v-strings and version objects, as well as the fact that $^V has changed its behavior in the past, it is not actually better than $]. Since $] always works, and always works the same way, we should encourage its use rather than $^V's. We can accomplish that by discouraging the use of $^V, in favor of $], in the docs.
#####

Please find attached a documentation patch which implements this approach.

--
James E Keenan (jkeenan@​cpan.org)

From @jkeenan

From 342bbf6e755801a521528c1bca0aee210ddede5e Mon Sep 17 00:00:00 2001
From: James E Keenan <jkeenan@cpan.org>
Date: Mon, 8 Dec 2014 20:28:59 -0500
Subject: [PATCH] Encourage use of $] over $^V.

---
 pod/perlvar.pod | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/pod/perlvar.pod b/pod/perlvar.pod
index 8561eb8..bcf24af 100644
--- a/pod/perlvar.pod
+++ b/pod/perlvar.pod
@@ -676,7 +676,9 @@ C<"%vd"> conversion:
 See the documentation of C<use VERSION> and C<require VERSION>
 for a convenient way to fail if the running Perl interpreter is too old.
 
-See also C<$]> for an older representation of the Perl version.
+C<$]> is an older representation of the Perl version which is preferable to
+C<$^V> in many situations because its meaning has not changed from one Perl
+version to another.
 
 This variable was added in Perl v5.6.0.
 
@@ -2273,9 +2275,6 @@ Deprecated in Perl v5.12.0.
 =item $]
 X<$]>
 
-See L</$^V> for a more modern representation of the Perl version that allows
-accurate string comparisons.
-
 The version + patchlevel / 1000 of the Perl interpreter.  This variable
 can be used to determine whether the Perl interpreter executing a
 script is in the right range of versions:
@@ -2290,6 +2289,9 @@ for a convenient way to fail if the running Perl interpreter is too old.
 
 Mnemonic: Is this version of perl in the right bracket?
 
+See L</$^V> for a more recent -- but not necessarily better -- representation
+of the Perl version that allows accurate string comparisons.
+
 =back
 
 =cut
-- 
1.9.1

From @jkeenan

Summary of my perl5 (revision 5 version 21 subversion 5) configuration​:
  Commit id​: e96513a
  Platform​:
  osname=linux, osvers=3.13.0-35-generic, archname=x86_64-linux
  uname='linux zareason 3.13.0-35-generic #62-ubuntu smp fri aug 15 01​:58​:42 utc 2014 x86_64 x86_64 x86_64 gnulinux '
  config_args='-des -Dusedevel -DDEBUGGING'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.8.2', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
  libs=-lnsl -ldl -lm -lcrypt -lutil -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.19.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.19'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl)​:
  Compile-time options​: DEBUGGING HAS_TIMES PERLIO_LAYERS
  PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
  PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV
  PERL_USE_DEVEL USE_64_BIT_ALL USE_64_BIT_INT
  USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE
  USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME
  USE_PERLIO USE_PERL_ATOF
  Built under linux
  Compiled at Sep 21 2014 09​:47​:45
  %ENV​:
  PERL5LIB="/home/jkeenan/perl5/lib/perl5"
  PERLBREW_BASHRC_VERSION="0.67"
  PERLBREW_HOME="/home/jkeenan/.perlbrew"
  PERLBREW_MANPATH="/home/jkeenan/perl5/perlbrew/perls/perl-5.20.0/man"
  PERLBREW_PATH="/home/jkeenan/perl5/perlbrew/bin​:/home/jkeenan/perl5/perlbrew/perls/perl-5.20.0/bin"
  PERLBREW_PERL="perl-5.20.0"
  PERLBREW_ROOT="/home/jkeenan/perl5/perlbrew"
  PERLBREW_VERSION="0.67"
  PERL_LOCAL_LIB_ROOT="/home/jkeenan/perl5"
  PERL_MB_OPT="--install_base "/home/jkeenan/perl5""
  PERL_MM_OPT="INSTALL_BASE=/home/jkeenan/perl5"
  PERL_WORKDIR="gitwork/perl"
  @​INC​:
  lib
  /home/jkeenan/perl5/lib/perl5/x86_64-linux
  /home/jkeenan/perl5/lib/perl5
  /usr/local/lib/perl5/site_perl/5.21.5/x86_64-linux
  /usr/local/lib/perl5/site_perl/5.21.5
  /usr/local/lib/perl5/5.21.5/x86_64-linux
  /usr/local/lib/perl5/5.21.5
  .

From @cpansprout

On Mon Dec 08 17​:35​:36 2014, jkeenan wrote​:

In a perl5-porters list discussion beginning here​:

http​://markmail.org/search/?q=perl5-porters#query​:perl5-
porters%20order%3Adate-
backward+page​:2+mid​:yzcyfzizqig6vmoy+state​:results

Ricardo Signes wrote​:

#####
A few times lately, $^V has come up in the context of being "the
better way to check the version than $]." This surprised me, because I
always thought it was largely considered better avoided.

I suggest that given the general confusion around v-strings and
version objects, as well as the fact that $^V has changed its behavior
in the past, it is not actually better than $]. Since $] always works,
and always works the same way, we should encourage its use rather than
$^V's. We can accomplish that by discouraging the use of $^V, in favor
of $], in the docs.
#####

Please find attached a documentation patch which implements this
approach.

I like your patch.

--

Father Chrysostomos

The RT System itself - Status changed from 'new' to 'open'

From @ap

* James E Keenan <perlbug-followup@​perl.org> [2014-12-09 02​:40]​:

Please find attached a documentation patch which implements this
approach.

I think this is the right general idea with not just telling people to
lay off the $], but I do not think this patch should be applied as is.

“Preferable in many cases” – which cases? “Not necessarily better” –
so… how does it differ? There is one reason given ($] has been a stable
interface), but it’s not clear if that is *the* reason or only one of
them, and what other advantages or problems there may be with either.

So it essentially says “$^V is newer but we won’t endorse it for unclear
reasons… though we’re not about to tell you not to use it either. Just
figure it out.” It implies a preference but then weasels its way out of
stating it outright. Not helpful.

Helpful would be for the docs to provide clear guidance. They ought to
state either a clear preference for either variable or be explicit that
either is fine. Ideally they should explain the issues, particularly in
the neutral preference case. A user reading the docs should come away
knowing which variable they want to use and why.

So let’s start with $] – what problems are there or have there been with
that one? And then likewise for $^V – what are the concerns? Once those
points are gathered, then an informative patch can be formulated.

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

From @Abigail

On Tue, Dec 09, 2014 at 03​:27​:14AM -0800, Aristotle Pagaltzis via RT wrote​:

* James E Keenan <perlbug-followup@​perl.org> [2014-12-09 02​:40]​:

Please find attached a documentation patch which implements this
approach.

I think this is the right general idea with not just telling people to
lay off the $], but I do not think this patch should be applied as is.

“Preferable in many cases” – which cases? “Not necessarily better” –
so… how does it differ? There is one reason given ($] has been a stable
interface), but it’s not clear if that is *the* reason or only one of
them, and what other advantages or problems there may be with either.

So it essentially says “$^V is newer but we won’t endorse it for unclear
reasons… though we’re not about to tell you not to use it either. Just
figure it out.” It implies a preference but then weasels its way out of
stating it outright. Not helpful.

Helpful would be for the docs to provide clear guidance. They ought to
state either a clear preference for either variable or be explicit that
either is fine. Ideally they should explain the issues, particularly in
the neutral preference case. A user reading the docs should come away
knowing which variable they want to use and why.

So let’s start with $] – what problems are there or have there been with
that one? And then likewise for $^V – what are the concerns? Once those
points are gathered, then an informative patch can be formulated.

I'm all for documentation that doesn't voice opinions. It should give
the reader facts, and (unbiased) arguments, so the reader can decide
what's best for her/him.

Abigail

From @Tux

On Tue, 9 Dec 2014 17​:54​:06 +0100, Abigail <abigail@​abigail.be> wrote​:

I have no idea why this went off-list ...

So let’s start with $] – what problems are there or have there been with
that one? And then likewise for $^V – what are the concerns? Once those
points are gathered, then an informative patch can be formulated.

I'm all for documentation that doesn't voice opinions. It should give
the reader facts, and (unbiased) arguments, so the reader can decide
what's best for her/him.

Wholeheartedly agree

Abigail

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

From @jkeenan

On Tue Dec 09 09​:10​:01 2014, hmbrand wrote​:

On Tue, 9 Dec 2014 17​:54​:06 +0100, Abigail <abigail@​abigail.be> wrote​:

I have no idea why this went off-list ...

So let’s start with $] – what problems are there or have there been with
that one? And then likewise for $^V – what are the concerns? Once those
points are gathered, then an informative patch can be formulated.

I'm all for documentation that doesn't voice opinions. It should give
the reader facts, and (unbiased) arguments, so the reader can decide
what's best for her/him.

Wholeheartedly agree

Abigail

Alright, since you all didn't like my patch, could someone else produce one?

Thank you very much.
Jim Keenan
--
James E Keenan (jkeenan@​cpan.org)

From @ap

* James E Keenan via RT <perlbug-followup@​perl.org> [2014-12-10 01​:10]​:

Alright, since you all didn't like my patch, could someone else
produce one?

Yes, once there are answers to these questions​:

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2014-12-09 12​:30]​:

So let’s start with $] – what problems are there or have there been
with that one? And then likewise for $^V – what are the concerns?

I don’t have them, which is why I haven’t offered a patch so far.

From @Leont

On Tue, Dec 9, 2014 at 12​:26 PM, Aristotle Pagaltzis <pagaltzis@​gmx.de>
wrote​:

Helpful would be for the docs to provide clear guidance. They ought to
state either a clear preference for either variable or be explicit that
either is fine. Ideally they should explain the issues, particularly in
the neutral preference case. A user reading the docs should come away
knowing which variable they want to use and why.

So let’s start with $] – what problems are there or have there been with
that one? And then likewise for $^V – what are the concerns? Once those
points are gathered, then an informative patch can be formulated.

$] has a numeric notation that doesn't match the semantic version notation
we've been using when communicating with humans since 5.6.0​: you have to
know to write 5.20.1 as 5.020001.

$^V has the issue of radically changing its behavior in 5.10. Its
stringication is human-friendly on 5.10+ (though I'd personally prefer it
without the v prefix), the numification gives exactly the same result as
$].

Leon

From @khwilliamson

On 12/10/2014 08​:30 AM, Leon Timmermans wrote​:

On Tue, Dec 9, 2014 at 12​:26 PM, Aristotle Pagaltzis <pagaltzis@​gmx.de
<mailto​:pagaltzis@​gmx.de>> wrote​:

Helpful would be for the docs to provide clear guidance\. They ought to
state either a clear preference for either variable or be explicit that
either is fine\. Ideally they should explain the issues\, particularly in
the neutral preference case\. A user reading the docs should come away
knowing which variable they want to use and why\.

So let’s start with $\] – what problems are there or have there been with
that one? And then likewise for $^V – what are the concerns? Once those
points are gathered\, then an informative patch can be formulated\.

$] has a numeric notation that doesn't match the semantic version
notation we've been using when communicating with humans since 5.6.0​:
you have to know to write 5.20.1 as 5.020001.

$^V has the issue of radically changing its behavior in 5.10. Its
stringication is human-friendly on 5.10+ (though I'd personally prefer
it without the v prefix), the numification gives exactly the same result
as $].

Leon

Something like​:

If you need to distinguish between versions that are lt 5.6.0, you have
to use $[. If you have to support versions lt 5.10, it's probably
better to use $[ so that you don't have to deal with the $^V behavior
differences. If you only need to deal with 5.10 and later, $^V provides
a cleaner syntax.

From @cpansprout

On Wed Dec 10 16​:38​:31 2014, public@​khwilliamson.com wrote​:

Something like​:

If you need to distinguish between versions that are lt 5.6.0, you
have
to use $[. If you have to support versions lt 5.10, it's probably
better to use $[ so that you don't have to deal with the $^V behavior
differences. If you only need to deal with 5.10 and later, $^V
provides
a cleaner syntax.

But with $], of course. :-) (Is this version of Perl in the right bracket?)

--

Father Chrysostomos

From @khwilliamson

I'm closing this ticket, as different text was eventually applied which makes this overtaken-by-events. I'll add a sentence to perlvar that emphasizes that the behaviour of $] hasn't changed since its inception

Karl Williamson

@khwilliamson - Status changed from 'open' to 'resolved'