Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 25879 invoked from network); 4 Sep 2002 14:16:46 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Sep 2002 14:16:46 -0000 Received: (qmail 10079 invoked by uid 97); 4 Sep 2002 14:17:14 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 10048 invoked by uid 97); 4 Sep 2002 14:17:12 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 10008 invoked by uid 98); 4 Sep 2002 14:17:11 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Subject: RE: [httpclient][patch] StatusLine encapsulation From: Ryan Lubke To: Jakarta Commons Developers List In-Reply-To: <1031147798.1448.26.camel@rivendell> References: <3549C09B853DD5119B540002A52CDD3404B0067C@zcard0ka.ca.nortel.com> <1031147798.1448.26.camel@rivendell> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.8 Date: 04 Sep 2002 10:11:04 -0400 Message-Id: <1031148669.1448.32.camel@rivendell> Mime-Version: 1.0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N OK, final bit on this an I'm shutting up. My memory on certification is rusty :) On Wed, 2002-09-04 at 09:56, Ryan Lubke wrote: > On Wed, 2002-09-04 at 09:36, Jeff Dever wrote: > > What you say is true Ryan, but the question is "if I write a constructo= r, is > > super() called implicitly in that constructor?" I don't know the answe= r to > > this. > --- Expanded on previous email --- >=20 > My point was that I don't believe super() will be added to all > constructors by default as Ortwin seemed to imply. My point was what > you write is what you get in the case of declared constructors. It appears that super() will be added implicitly. Given: class test { public test() { System.out.println("test"); } } class test1 extends test { public test1() { System.out.println("test1"); } } In this case both test and test1 are printed. Given: class test { public test(String foo) {} } class test1 { public test1() {} } This will fail as test doesn't have an explicitly declared=20 no-arg constructor (this is what I was thinking at the time I read Ortwin's mail). Anyway, time to drop off the list for a bit and bury my head in shame. >=20 > It wouldn't make sense to always add a super() call implicitly to each > constructor. If the super class declares a constructor, but doesn't > declare a no-arg constructor, then you're dead in the water. =20 > =20 > > But I had a look at the sun source for Object.java: it is undeclared. = There > > are no constructors declared for Object so the compiler would generate = the > > default one. There are no instance variables in the class so the gener= ated > > constructor would be empty.=20 > >=20 > > Therefore, it would be better to leave out the call to super() when > > extending class Object. >=20 > That's fine. > >=20 > > BTW: there is some effort in gjc to optimize away the call to the empty > > Object constructor, so this is another reason to leave out the explicit > > call. >=20 > Yes, I saw that. > >=20 > >=20 > > -----Original Message----- > > From: Ryan Lubke [mailto:Ryan.Lubke@Sun.COM] > > Sent: Wednesday, September 04, 2002 8:28 AM > > To: Jakarta Commons Developers List > > Subject: Re: [httpclient][patch] StatusLine encapsulation > >=20 > >=20 > > Actually, I think it's only done on the behalf of the developer in the > > case where the class has no constructor. A no-arg constructor will be > > added to the class with a call to super(). In cases where you have an > > explicit constructors, what you see is what you get. > >=20 > >=20 > >=20 > > On Wed, 2002-09-04 at 04:31, Ortwin Gl=FCck wrote: > > > All very nice. And it's compatible with existing code. > > >=20 > > > My critizism is only cosmetics: you can ommit the call to super() in = the=20 > > > constructor (it's always done automatically). > > >=20 > > > Jeff Dever wrote: > > > > This is my response for the bug: > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=3D12245 > > > >=20 > > > > I added a new StatusLine class and added it as an instance variable= to > > > > HttpMethodBase. Removed individual statusCode and statusText membe= rs. > > > > Removed the parsing of the status line into the StatusLine construc= tor. > > > > HttpMethodBase.readStatusLine() still checks for the http version a= nd > > > > sets the (dreaded) isHttp11 boolean. There was an interface change= to > > > > the HttpMethod interface to getStatusLine(). > > > >=20 > > > > I like this solution as it get some of the code out of HttpMethodBa= se > > > > and recognizes the uniqueness of the Status-Line. > > > >=20 > > > > What do ya'll think? > > > >=20 > > > > PS: This is based on a suggestion by Vincent Massol. > > >=20 > > >=20 > > >=20 > > >=20 > > > -- > > > To unsubscribe, e-mail: > > > > > For additional commands, e-mail: > > > > >=20 > >=20 > >=20 > >=20 > > -- > > To unsubscribe, e-mail: > > > > For additional commands, e-mail: > > > >=20 >=20 >=20 >=20 > -- > To unsubscribe, e-mail: > For additional commands, e-mail: >=20 -- To unsubscribe, e-mail: For additional commands, e-mail: