[
https://issues.apache.org/jira/browse/HTTPCORE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513235
]
Roland Weber commented on HTTPCORE-101:
---------------------------------------
With alpha5, Oleg made sure that parameters passed to the framework will be
copied so they don't get modified by accident. I don't see how this approach
would fit reasonably with a read-only interface. Either you get unnecessary
params duplications, or you need ugly read-only wrappers to prevent such
duplications. (Assuming that read-only parameters would implement the
copyParams() method as "return this".)
I tend to leave things as they are, unless we run into serious problems with
it. By serious problems, I mean user feedback that the API is too tricky to
use, or performance problems, or other such stuff. Something beyond "it would
be nice..."
We know our documentation is lacking, and that includes the parameterization
framework. But maybe it's better to address this by writing documentation
rather than by twisting the API to require less documentation?
cheers,
Roland
> Consider read-only HttpParams
> -----------------------------
>
> Key: HTTPCORE-101
> URL: https://issues.apache.org/jira/browse/HTTPCORE-101
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore, HttpCore NIO
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Priority: Minor
> Fix For: 4.0-alpha6
>
>
> Consider turning HttpParams into a read-only interface, moving modifiers to
> an extension interface.
> Suggested by Daniel Müller on httpcomponents-dev.
> This will break the following style of updating existing parameters:
> xxx.getParams().setParameter("name", value);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
