commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Lubke <Ryan.Lu...@Sun.COM>
Subject RE: [httpclient][patch] StatusLine encapsulation
Date Wed, 04 Sep 2002 14:11:04 GMT
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 constructor, is
> > super() called implicitly in that constructor?"  I don't know the answer to
> > this.
> --- Expanded on previous email ---
> 
> 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 
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.


> 
> 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.  
>  
> > 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 generated
> > constructor would be empty. 
> > 
> > Therefore, it would be better to leave out the call to super() when
> > extending class Object.
> 
> That's fine.
> > 
> > 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.
> 
> Yes, I saw that.
> > 
> > 
> > -----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
> > 
> > 
> > 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.
> > 
> > 
> > 
> > On Wed, 2002-09-04 at 04:31, Ortwin Gl├╝ck wrote:
> > > All very nice. And it's compatible with existing code.
> > > 
> > > My critizism is only cosmetics: you can ommit the call to super() in the 
> > > constructor (it's always done automatically).
> > > 
> > > Jeff Dever wrote:
> > > > This is my response for the bug:
> > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=12245
> > > > 
> > > > I added a new StatusLine class and added it as an instance variable to
> > > > HttpMethodBase.  Removed individual statusCode and statusText members.
> > > > Removed the parsing of the status line into the StatusLine constructor.
> > > > HttpMethodBase.readStatusLine() still checks for the http version and
> > > > sets the (dreaded) isHttp11 boolean.  There was an interface change to
> > > > the HttpMethod interface to getStatusLine().
> > > > 
> > > > I like this solution as it get some of the code out of HttpMethodBase
> > > > and recognizes the uniqueness of the Status-Line.
> > > > 
> > > > What do ya'll think?
> > > > 
> > > > PS: This is based on a suggestion by Vincent Massol.
> > > 
> > > 
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> > > 
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message