DO NOT REPLY [Bug 39180] - Subclasses do not have write access to StatusLine

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39180>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39180


olegk@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |
            Summary|Subclasses do not have      |Subclasses do not have write
                   |access to StatusLine        |access to StatusLine




------- Additional Comments From olegk@apache.org  2006-04-04 12:51 -------
(In reply to comment #7)
> If I have offended you then I appologize. I did not open this issue just because
> I think it could be done a better way. I have not commented on the suitability
> of the code. I would like to try again :-)
> 

No offense taken at all. The point I was trying to make (rather unsuccessfully)
is that merits of what some may consider a good practice tend to be subjective
and context specific. 

> readResponse enters a loop looking for a non-null statusLine. readStatusLine is
> responsible for setting the variable to a non-null value. If I override
> readStatusLine I cannot set the variable and readResponse is stuck in the loop.
> I cannot override getStatusLine since readResponse uses the variable directly.
> 
> I see four solutions here. Never override readStatusLine (should be private),
> make variable protected, add a setter, or change code to use existing getter.
> Any of the last three will work for me.
> 
> The same problems exist with the other member variables; I just used statusLine
> as an example. I can resubmit the patch for any solution you choose and I can
> ensure that all member variables are accessed in a consistent manner.

My preference would be to make those variables protected. 

HttpMethodBase (imho) is a horrible pile of <self-censored> broken beyond
redemption. I just want to keep it as stable as possible in the 3.x branch and
do away with it in the 4.x branch

Oleg

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org