develooper Front page | perl.perl5.porters | Postings from June 2013

Re: What does "deprecated" mean? (was: [perl #118511] Use of bare<< to mean <<"" is deprecated - make a hard error)

Thread Previous | Thread Next
Peter Rabbitson
June 27, 2013 08:55
Re: What does "deprecated" mean? (was: [perl #118511] Use of bare<< to mean <<"" is deprecated - make a hard error)
Message ID:
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 

> 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 

> 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 

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.



Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About