develooper Front page | perl.perl5.porters | Postings from December 2015

Re: [perl #127060] remove deprecated *glob{FILEHANDLE}

Thread Previous | Thread Next
December 28, 2015 22:04
Re: [perl #127060] remove deprecated *glob{FILEHANDLE}
Message ID:
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: >
> This is a bug report for perl from,
> 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

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?


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About