Front page | perl.perl5.porters |
Postings from June 2013
On Thu, Jun 27, 2013 at 05:56:36PM +1000, Peter Rabbitson wrote: > I am taking this thread out of the RT queue. > > On Thu, Jun 27, 2013 at 09:44:02AM +0200, demerphq wrote: > > 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. I don't agree with the absolute here. But I totally agree with the concern. If things are marked as deprecated but seemingly never removed, then a) The reasons for marking them as such are ambiguous, rather than clear b) People will ignore the desired intent of the warnings (to stop using this) > 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. I see your point, but I think that you are contradicting yourself here. Given that you already described the warnings as meaning "do not complain when it is gone", then others should not be complaining if the deprecated feature is pulled promptly. Also, given that there is no reliable timeframe on deprecation eliminations, it's not actually possible for anyone to perform a cost-benefit analysis of whether to deal with it now or "at the time of removal", because without a timeframe for the latter, it's impossible to calculate the correct discount for future work. For calculation purposes, it would actually be better to stick to a firm timescale, instead of deferring as long as possible. I know *why* things are deprecated, because (one of) 1) we think that they are going to get in the way of a net more useful thing 2) with hindsight, they shouldn't be part of the design (they add more in complexity than they deliver in benefits) 3) they are becoming impossible to maintain But the trade off is getting the balance right to make the end user pain of fixing less than the end user pain of not fixing, so that we keep (most) of the end users. I don't have an answer here, but I'm not convinced that the end-member positions are correct. I'm wondering if the least worst answer is that we have a policy of removing things "not later than" a "long but bounded" time in the future. eg *) we may remove it two major releases after it is first deprecated *) we will remove it five major releases after it is first deprecated Nicholas ClarkThread Previous | Thread Next