hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Dever <jsde...@sympatico.ca>
Subject Re: [PATCH] You see, it did not even hurt [no more disk buffering in GetMethod]
Date Fri, 24 Jan 2003 16:31:16 GMT
Use cases:
Someone already using the useDisk methods
*Impact of removeal*  If the methods were working for the user, they 
will be annoyed in having their compilation broken and have to search 
for how to get the same functionality.  If the methods were not working 
for the user (ie found bugs) then they would not be using the methods 
*Impact of deprecation* The user will discover that the methods are no 
longer supported and can change to the new way at their leisure.  The 
@deprecated comment will give the user information on how to achieve 
equivelent functionality.

Someone new looking to use the useDisk methods
*Impact of removeal* They will never see the methods and will be 
insulated from futher api changes
*Impact of deprecation* They will see they are deprecated and are warned 
not to use them

In terms of "lesser of two evils" I'd say that strictly removing the 
methods without warning is worse.  We should just deprecate the 
methods/members in question with a comment on how to do the same thing 
in a different way.  

To address Orthanc's comment about how much the public interface has 
changed already, this is true, but each circumstance was considered on 
its own merit.  For example, the HttpMultiClient and related changes 
were just too complex to deprecate and provide the new functionality 
cleanly.  They were never part of alpha 1 anyway, so they were simply 
scrapped.  In this case, we can deprecate easily, and useDisk has been 
in there since the very first revision.  Therefore, we should deprecate.

I greatly respect your opinions, but the case for deprecation is very 


Michael Becke wrote:

> On Friday, January 24, 2003, at 07:17 AM, Christopher Lenz wrote:
>> Kalnichevski, Oleg wrote:
>>> Chris
>>> I see your point. However, let me reiterate a few points that I deem 
>>> important too. It's not just about clean API. The code we would like 
>>> to deprecate contains bugs. I personally see no sense in fixing 
>>> stuff that does not make sense.  I see removal of that code as a 
>>> lesser evil compared to releasing buggy code
>> Just deprecate it and say it is buggy in the Javadocs. Then API 
>> clients will have a chance to migrate their code before their builds 
>> fail.
>> Deprecation is all about informing users about parts of the code that 
>> may not work correctly, will not me fixed/maintained and will 
>> probably be removed in one of the following releases.
>> -chris
> Agreed.  Anyone using this functionality has found a way to make it 
> work.  Otherwise they would not be using it.
> Mike
> --
> To unsubscribe, e-mail:   
> <mailto:commons-httpclient-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-httpclient-dev-help@jakarta.apache.org>

View raw message