On Thu, Jun 27, 2013 at 09:44:13PM +0200, Aristotle Pagaltzis wrote: > * Peter Rabbitson <rabbit-p5p@rabbit.us> [2013-06-27 09:15]: > > 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 > > Historically, there has been a problem in removing features that had > been marked deprecated for so long that people stopped caring about > their status as deprecated. > > The point of tension here, to which a solution would be welcome if you > can propose one, is this: is there a way to extinguish its use in newly > written code? Is this really the point of tension though? Let's take a much less obscure example: a user buys a fresh book about perl and proceeds using the shiny ~~ syntax. A set of loud warnings is emitted. If the user proceeds writing code *despite* these warnings - is it really anyone elses problem at this point...? Maybe the argument here is "but not everyone uses warnings", which is somewhat true. In an ideal world lexical warnings would be a tri-state, with some warnings (deprecation, and reeeeeally ominous ones) being on by default, and others being off by default, with the usual control with use/no warnings. We don't have that. However what we have is an army of modules which unapologetically import pragmas into the callers namespace. So many in fact that it is becoming increasingly unlikely that new code will not get warnings implicitly turned on in many parts of the source. This still leaves us with the problem of oneliners which are not instrumented wrt deprecation warnings. I concede I do not have a good solution for this, and as such chalking this up for "the cost of doing business" seems the only solutions. Still my question stands - is the threat of new code using *visibly* deprecated features really that severe...? CheersThread Previous | Thread Next