Front page | perl.perl5.porters |
Postings from June 2013
On Thu, Jun 27, 2013 at 09:34:01AM +0100, Nicholas Clark wrote: > 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. I dropped some context that was present in my original mail [1]. In it I said: > 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. To summarize/clarify my position: An end-user has no right to complain that a deprecated feature got in the way of something and was removed. An end user could very well complain that a feature was gone without a technical reason (see below). > > 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. You know very well that this is not how the real world of PHBs work. The usual cost-benefit analysis is framed roughly as "Alrighty, out of this pile of technical debt, what do we have to do NOW and what can we do NOT NOW" > 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 These are all excellent guidelines (as long as 2 retains its bracketed disclaimer) 1) seems to be the case for the feature in question - namely <<''. It has already been deprecated as such. And its users (in this case FC) conceeded that if a saner use comes along he will let it go. With all that - what is the benefit of breaking his actual existing code now, instead of when the use case for <<'' becomes clear? > 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 This would be a reasonable timeline, except I still fail to see the urge to break something without a clear technical need. Cheers [1] http://www.nntp.perl.org/group/perl.perl5.porters/2013/06/msg203778.htmlThread Previous | Thread Next