On 21/06/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > On Sat, 2008-06-21 at 12:00 +0100, sebb wrote: > > There seem to be quite a few people who assume the HttpParams class is > > something to do with parameters used in HTTP requests. > > > > It's probably too late now, but is it worth considering renaming > > HttpParams to avoid this confusion? I suspect the confusion will never > > entirely disappear. > > > > > I agree, but what do we about the API freeze? Make an exception? >
It's a bit different from changing method parameters etc, in that a simple search-replace can be used, but it would still be a pain for users. Maybe it should be raised on the user list. As mitigation, I think one can keep the old interface and deprecate it. This could be done by changing HttpParam to ConfigParam (for example) throughout (only 619 matches in trunk!) Then make ConfigParam extend HttpParam. Both would have the same content (Java does not seem to mind this). Later, the extend clause and the HttpParam class could be dropped. There are some other classes which perhaps also need to be changed for consistency: AbstractHttpParams BasicHttpParams DefaultedHttpParams I think the same "deprecated parent" approach could be used with these (though obviously the final clauses would need to be removed from the parent classes). In the meantime, the Javadoc for HttpParams should be updated; it would be helpful if it also referenced the classes used for handling HTTP Parameters. > Oleg > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
