Front page | perl.perl5.porters |
Postings from June 2013
On 27 June 2013 09:12, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote: > On Thu, Jun 27, 2013 at 05:35:38AM +0000, Ed Avis wrote: >> If it's not possible to change this deprecation to a hard error (after a decade or so of warning) for fear it will break working scripts, what hope is there of the deprecation-removal cycle working for anything? > > I think what FC is pointing out is: > > IFF a feature was deprecated because if was broken OR because it needed > to free up syntax for something infinitely more consistent and/or useful - > then removal after an announced deprecation is fair game. > > However there is no ground for removal of a deprecated feature, which > already issues warnings to such effect (i.e. newbies will not use such > features mistakenly). By removing stuff solely to "honor a promise" is > creating work for darkpan users with the sole benefit of pleasing > someone aesthetically. > > A quote of the irc.perl.org#dbic-cabal topic seems relevant: > >> deprecated modules get deleted when they cause a problem and not before > > My 2c I think you are confusing "discouraged" and "deprecated". If a feature is something that should not be used in production code but is allowed then its use should be discouraged in the documentation, and not marked as deprecated run time warning. If we use the term "deprecated" to mean "discouraged" then the word "deprecated" and the warnings it generate are meaningless and will be ignored, and then there is no point in having them. Once a feature is marked as deprecated we should rigorously follow through, otherwise there is no point in having the warning at all. We could manage all of this in the documentation. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next