DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture ------- Additional Comments From [EMAIL PROTECTED] 2003-09-22 11:44 ------- > 1. public HttpClient(HttpClientParams params) > Can we add something like HttpConnectionManager.setParams(p)? HttpParams-enable HttpConnection & HttpConnectionManager is the next item on my list. > 2. DefaultHttpParams.clone() > I believe the clone method is a little too smart. Think of the most > common and simple case. Actually I spent a healthy part of my last weekend studying different approaches to object cloning in Java. General sentiment is that java.lang.Object#clone() and java.lang.Cloneable are just plan broken. There are enough folks out there who believe that object serialization is the only way to go. I am a bit reluctant to put constraints on type of objects that may be used as parameter values as there's always a chance that we may overlook a legitimate use pattern. I would also prefer to use Collection classes instead of arrays as things may turn ugly if one wanted, for instance, just to add one additional DateFormat to the standard set of DateFormats. All that array content juggling can get a bit messy I agree my clone method does appear to be an overkill, but that was the only approach which I felt was robust enough to handle all sorts of cases without running a risk of screwing things up in a subtle way. Anyways, I do not mind having a simpler method, but first of all, we need to agree on what type of objects we should allow as parameter values. My opinion that we should allow all Cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
