remove deprecated *glob{FILEHANDLE}

[p5pRT]

Migrated from rt.perl.org#127060 (status was 'resolved')

Searchable as RT127060$

[p5pRT]

From @rjbs

Created by @rjbs

Using *glob{FILEHANDLE} instead of *glob{IO} was intended to be
deprecated in 1996 or so, but it didn't done until
39b99f2, in Sep, 2001.

This behavior has been issuing a warning since then, and it has been
default-on since 5.12.0 in April 2010.

I'm not sure there's an obvious way forward here, but I would like to
figure out whether we can (should?) try to close out all our
longstanding deprecations.

1) drop the behavior entirely, letting it return undef like any other
  unknown glob entry

2) make it fatal

3) leave it warning but working

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.23.3:

Configured by rjbs at Mon Sep 21 11:54:00 EDT 2015.

Summary of my perl5 (revision 5 version 23 subversion 3) configuration:
   
  Platform:
    osname=darwin, osvers=14.5.0, archname=darwin-2level
    uname='darwin jubjub.local 14.5.0 darwin kernel version 14.5.0: wed jul 29 02:26:53 pdt 2015; root:xnu-2782.40.9~1release_x86_64 x86_64 '
    config_args='-Dprefix=/Users/rjbs/.plenv/versions/23.3 -de -Dusedevel -A'eval:scriptdir=/Users/rjbs/.plenv/versions/23.3/bin''
    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 ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -I/opt/local/include',
    optimize='-O3',
    cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -I/opt/local/include'
    ccversion='', gccversion='4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3
    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='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector-strong -L/usr/local/lib -L/opt/local/lib'
    libpth=/usr/local/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.0.0/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib /usr/lib /opt/local/lib
    libs=-lpthread -lgdbm -ldbm -ldl -lm -lutil -lc
    perllibs=-lpthread -ldl -lm -lutil -lc
    libc=, so=dylib, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/local/lib -fstack-protector-strong'



@INC for perl 5.23.3:
    /Users/rjbs/.plenv/versions/23.3/lib/perl5/site_perl/5.23.3/darwin-2level
    /Users/rjbs/.plenv/versions/23.3/lib/perl5/site_perl/5.23.3
    /Users/rjbs/.plenv/versions/23.3/lib/perl5/5.23.3/darwin-2level
    /Users/rjbs/.plenv/versions/23.3/lib/perl5/5.23.3
    .


Environment for perl 5.23.3:
    DYLD_LIBRARY_PATH (unset)
    HOME=/Users/rjbs
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/Users/rjbs/.plenv/versions/23.3/bin:/Users/rjbs/.plenv/libexec:/Users/rjbs/.plenv/plugins/perl-build/bin:/Users/rjbs/bin:/Users/rjbs/.rbenv/shims:/Users/rjbs/.rbenv/bin:/Users/rjbs/.rakudobrew/bin:/Users/rjbs/.plenv/shims:/Users/rjbs/.plenv/bin:/opt/local/bin:/opt/local/sbin:/usr/local/texlive/2015/bin/x86_64-darwin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/Users/rjbs/code/hla
    PERLDOC=-otext
    PERL_AUTOINSTALL=--skipdeps
    PERL_BADLANG (unset)
    PERL_MAILERS=sendmail:/Users/rjbs/bin/sendmail
    SHELL=/opt/local/bin/zsh

[p5pRT]

From @Abigail

On Mon, Dec 28, 2015 at 12​:34​:32PM -0800, Ricardo SIGNES wrote​:

# New Ticket Created by Ricardo SIGNES
# Please include the string​: [perl #127060]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=127060 >

This is a bug report for perl from rjbs@​cpan.org,
generated with the help of perlbug 1.40 running under perl 5.23.3.

-----------------------------------------------------------------
[Please describe your issue here]

Using *glob{FILEHANDLE} instead of *glob{IO} was intended to be
deprecated in 1996 or so, but it didn't done until
39b99f2, in Sep, 2001.

This behavior has been issuing a warning since then, and it has been
default-on since 5.12.0 in April 2010.

I'm not sure there's an obvious way forward here, but I would like to
figure out whether we can (should?) try to close out all our
longstanding deprecations.

1) drop the behavior entirely, letting it return undef like any other
unknown glob entry

2) make it fatal

3) leave it warning but working

There's also a fourth option​:

  4) drop the warning, and leave it working.

If it was intended to be deprecated almost 20 years ago, and was
deprecated for more than 14 years, then what's the point? Whatever
itch was annoying people back then doesn't seem to require much
scratching nowadays.

I think having something deprecated for a long time, but all what's
being done is having a deprecation warning is bad for perl. On the
one hand, there's no gain, as the feature (and hence the code) is
still there. On the other hand, you're needlessly annoying the user,
forcing her to change her code for no other reason than silencing a
warning.

IMO, if something is deprecated, there should be a date attached.
By that date, either the feature is really gone (and hence, the benefit
of deprecating it can be reaped), or the feature should be undeprecated
again (that is, supported again).

Labelling features as deprecated, but then not deprecating them, will
cause people to ignore or silence deprecation warnings, as their experience
will learn them they aren't serious. And then people will get bitten if
some features do get deprecated.

If p5p doesn't take deprecation warnings seriously, why should users?

Abigail

[p5pRT]

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

[p5pRT]

From @rjbs

* Abigail via RT <perlbug-followup@​perl.org> [2015-12-28T17​:05​:25]

There's also a fourth option​:

4) drop the warning, and leave it working.

If it was intended to be deprecated almost 20 years ago, and was
deprecated for more than 14 years, then what's the point? Whatever
itch was annoying people back then doesn't seem to require much
scratching nowadays.

Yeah, and I think this is a pretty reasonable option. I meant to include it,
which is why I started with "close out" deprecations -- I just don't want them
hanging open forever.

*glob{FILEHANDLE} irritates me, but only when I notice that it's there. Is
there some benefit to getting rid of it? "It helps avoid confusion" might be
true in some sense, but it's undercut by the confusion that will be introduced
by existing working code failing.

IMO, if something is deprecated, there should be a date attached.
By that date, either the feature is really gone (and hence, the benefit
of deprecating it can be reaped), or the feature should be undeprecated
again (that is, supported again).

I agree, generally. Even if there is no date, it should be revisited
regularly. "my variable in false conditional" is an example where the
deprecation seems likely to linger intentionally.

If p5p doesn't take deprecation warnings seriously, why should users?

Agreed, and that's why I brought this up!

--
rjbs

[p5pRT]

From @ap

* Abigail <abigail@​abigail.be> [2015-12-28 23​:05]​:

There's also a fourth option​:

4) drop the warning, and leave it working.

  4b) but document it as discouraged

If it was intended to be deprecated almost 20 years ago, and was
deprecated for more than 14 years, then what's the point?

It’s probably one of these things that fell merely under “we don’t like
this”, and happened before discouraged-vs-deprecated was distinguished.

I think having something deprecated for a long time, but all what's
being done is having a deprecation warning is bad for perl.

Yeah.

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

[p5pRT]

From @rjbs

* Abigail <abigail@​abigail.be> [2015-12-28T17​:04​:39]

4) drop the warning, and leave it working.

Patch attached. Thoughts, folks?

--
rjbs

[p5pRT]

From @rjbs

0001-glob-FILEHANDLE-is-no-longer-deprecated.patch

From 97f82b9c9d336ca942bdd8f40d5aef723716e47c Mon Sep 17 00:00:00 2001
From: Ricardo Signes <rjbs@cpan.org>
Date: Thu, 31 Dec 2015 21:54:49 -0500
Subject: [PATCH] *glob{FILEHANDLE} is no longer deprecated

---
 pod/perlref.pod | 5 +++--
 pp.c            | 2 --
 t/op/gv.t       | 4 +++-
 t/uni/gv.t      | 4 +++-
 4 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/pod/perlref.pod b/pod/perlref.pod
index 5804c17..1546c61 100644
--- a/pod/perlref.pod
+++ b/pod/perlref.pod
@@ -272,8 +272,9 @@ the IO handle, used for file handles (L<perlfunc/open>), sockets
 (L<perlfunc/socket> and L<perlfunc/socketpair>), and directory
 handles (L<perlfunc/opendir>).  For compatibility with previous
 versions of Perl, C<*foo{FILEHANDLE}> is a synonym for C<*foo{IO}>, though it
-is deprecated as of 5.8.0.  If deprecation warnings are in effect, it will warn
-of its use.
+is discouraged, to encourage a consistent use of one name: IO.  On perls
+between v5.8.0 and v5.22.0, it will issue a deprecation warning, but this
+deprecation has been rescinded.
 
 C<*foo{THING}> returns undef if that particular THING hasn't been used yet,
 except in the case of scalars.  C<*foo{SCALAR}> returns a reference to an
diff --git a/pp.c b/pp.c
index 7071478..016023e 100644
--- a/pp.c
+++ b/pp.c
@@ -675,8 +675,6 @@ PP(pp_gelem)
 	    break;
 	case 'F':
 	    if (len == 10 && strEQ(second_letter, "ILEHANDLE")) {
-		/* finally deprecated in 5.8.0 */
-		deprecate("*glob{FILEHANDLE}");
 		tmpRef = MUTABLE_SV(GvIOp(gv));
 	    }
 	    else
diff --git a/t/op/gv.t b/t/op/gv.t
index 2c9cc64..6fd869c 100644
--- a/t/op/gv.t
+++ b/t/op/gv.t
@@ -182,7 +182,9 @@ is (*{*x{GLOB}}, "*main::STDOUT");
 	$warn .= $_[0];
     };
     my $val = *x{FILEHANDLE};
-    print {*x{IO}} ($warn =~ /is deprecated/
+
+    # deprecation warning removed in v5.23 -- rjbs, 2015-12-31
+    print {*x{IO}} (! defined $warn
 		    ? "ok $test\n" : "not ok $test\n");
     curr_test(++$test);
 }
diff --git a/t/uni/gv.t b/t/uni/gv.t
index 89905fd..7557ffb 100644
--- a/t/uni/gv.t
+++ b/t/uni/gv.t
@@ -190,7 +190,9 @@ is (*{*Ẋ{GLOB}}, "*main::STDOUT");
 	$warn .= $_[0];
     };
     my $val = *Ẋ{FILEHANDLE};
-    print {*Ẋ{IO}} ($warn =~ /is deprecated/
+
+    # deprecation warning removed in v5.23 -- rjbs, 2015-12-31
+    print {*Ẋ{IO}} (! defined $warn
 		    ? "ok $test\n" : "not ok $test\n");
     curr_test(++$test);
 }
-- 
2.6.4

[p5pRT]

From @cpansprout

On Thu Dec 31 19​:13​:48 2015, perl.p5p@​rjbs.manxome.org wrote​:

* Abigail <abigail@​abigail.be> [2015-12-28T17​:04​:39]

4) drop the warning, and leave it working.

Patch attached. Thoughts, folks?

Looks good to me.

--

Father Chrysostomos

[p5pRT]

From @jkeenan

On Thu Dec 31 19​:13​:48 2015, perl.p5p@​rjbs.manxome.org wrote​:

* Abigail <abigail@​abigail.be> [2015-12-28T17​:04​:39]

4) drop the warning, and leave it working.

Patch attached. Thoughts, folks?

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

[p5pRT]

From @jkeenan

On Thu Dec 31 19​:13​:48 2015, perl.p5p@​rjbs.manxome.org wrote​:

* Abigail <abigail@​abigail.be> [2015-12-28T17​:04​:39]

4) drop the warning, and leave it working.

Patch attached. Thoughts, folks?

Recommend including the RT number in inline comments and commit message.

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

[p5pRT]

From @Abigail

On Thu, Dec 31, 2015 at 10​:13​:22PM -0500, Ricardo Signes wrote​:

* Abigail <abigail@​abigail.be> [2015-12-28T17​:04​:39]

4) drop the warning, and leave it working.

Patch attached. Thoughts, folks?

Looks almost good to me​:

+between v5.8.0 and v5.22.0, it will issue a deprecation warning, but this

but this line suggests the warning is gone in 5.22.1, which I don't
think it is. Perhaps some wording like​:

  On perls since v.5.8.0, it will issue a deprecation warning, but
  this deprecation has been rescinded as of v5.23.0.

Or use the more math-like open ended interval​:

  On perls from v5.8.0, and before v5.23.0, it will ...

Or perhaps the easiest is to drop the '.0' altogether, and just use 5.8
and 5.22.

Abigail

[p5pRT]

From @rjbs

Thanks, applied as 83677dc.

:-)

--
rjbs

[p5pRT]

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