Front page | perl.perl5.porters |
Postings from June 2013
I am taking this thread out of the RT queue. On Thu, Jun 27, 2013 at 09:44:02AM +0200, demerphq wrote: > 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". No I am not. > 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. We (and I mean most of the developers I run across) use the term "deprecated" to mean "Marked as 'will disappear at any time in the future, without further warnings' - do not complain when it is gone". In other words for most of us deprecations are a way for developers to disclaim complaints about future demolition work. I never treat them as *promise* of demolition work. I suspect in your book this means I am ignoring deprecations by treating them thusly? > Once a feature is marked as deprecated we should rigorously follow > through, otherwise there is no point in having the warning at all. The warning is there so that the end user has time to run a cost benefit analysis and decide when to deal with the issue - either immediately, or when the inevitable finally comes. You have no right to make this decision for others, unless you are paying for their time. CheersThread Previous | Thread Next