First of all, this is documented syntax in 5.18, and I don't see it
deprecated anywhere in perlvar (which documents this variable name
What do you mean by that? All 5.20 did was to deprecate it. Are you saying
it should have been done in 5.18 instead???
It breaks existing code, and is yet another non-backwards compatible
change, is against perlpolicy, and was done for no comprehensible reason.
Secondly, I don't see why an existing warning category is
changed, again, in a backwards-incompatible way.
It's a new warning. It didn't have a category to change. Or are you saying
that each time a warning is added, a new category should be created for it.
I would actually greatly prefer that, but that's not really relevant, so I
don't want to go too deeply into this.
Except you just said it should have been deprecated in 5.18, so why are you
complaining about it getting deprecated in 5.20?!
Actually, it is you who said that, not me. I am clearly complaining about
backwards compatibility, and don't think it should be deprecated at all
(since there are no reasons to deprecate it, as opposed to e.g. adding a
new warning category).
Requiring end-user programmers to change just a few language constructs,
even language constructs which no well-educated developer would ever
intentionally use is tantamount to saying "you should not upgrade to a
new release of Perl unless you have 100% test coverage and can do a full
manual audit of your codebase."
What? It's a compile-time warning.
Yes, it is a compile time warning. You seem to think that changes
something - what?

                 The choice of a Deliantra, the free code+content MORPG
       -----==- _GNU_ http://www.deliantra.net
       ----==-- _ generation
       ---==---(_)__ __ ____ __ Marc Lehmann
       --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
       -=====/_/_//_/\_,_/ /_/\_\

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2021 Grokbase