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-19 12:31 -------
> Right, no-one should use the same params object for multiple clients or methods
> and expect setters to be invoked without side effects. That should be made
> clear in the JavaDocs for the constructors that accept params objects.

I agree this could cause some strange problems.  Is there even a case to share the 
same instance 
of a params object between multiple methods/clients?  If not, perhaps the constructor 
should 
always make copies.

> It would surely be useful if all params objects were cloneable. I'd say that
> on cloning, a params object should copy the parameters it holds locally, but
> keep the same reference for the default params. No need to clone defaults,
> since they are accessed read-only.

Sounds like a good idea.  I would suggest a copy constructor along with/instead of 
Cloneable as 
cloning can be a little ugly.

> While you're at it, can you add an "implements Serializable" as well?
> I don't know what it would be good for, but maybe someone someday wants
> do deserialize params objects in an HttpParamsFactory.

Agreed.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to