Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: super Date: Sun, 18 Sep 2011 13:16:39 -0700 (PDT) Organization: http://groups.google.com Lines: 72 Message-ID: <20064407.800.1316376999124.JavaMail.geo-discussion-forums@prdy8> References: <3e87dcf3-6842-41bf-8eb8-0c4181a178a9@k1g2000vbz.googlegroups.com> <797b5b56-9855-4ff1-a1e9-1eef2dcef7a8@d12g2000vba.googlegroups.com> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 24.6.43.78 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1316376999 18028 127.0.0.1 (18 Sep 2011 20:16:39 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 18 Sep 2011 20:16:39 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=24.6.43.78; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8141 Andreas Leitgeb wrote: > giuseppe.on.usenet wrote: >> Andreas Leitgeb wrote: >>> I think the misunderstanding is far more basic. >>> To giuseppe: >>> In dir2.GrandChild's main, just remove the line, where you instantiate >>> Child, and leave the rest exactly as is. =A0Recompile & run it. =A0You'= ll >>> see that instantiating class Child (or not doing it) doesn't change >>> anything. What does this tell you? >> >> I am not the author :) I found that code in a certification study >> guide (the original question was: What will the output be?). >=20 > That doesn't really matter. Obviously you didn't "guess" (or know) > the answer (or you wouldn't have asked here). If you are still > surprised by "super.var" and "var" being the same value, then > I advise you to still make the experiments I suggested. >=20 >> Maybe >> they instantiated the Child object just to try to confuse the reader. >=20 > Not primarily to confuse him, but rather to test his confusability ;-) Andreas is completely correct, giuseppe. It's a test question, so of cours= e they will include some irrelevant information ("red herrings") to see if = you really know what you're doing. It is completely unnecessary to use a compiler to answer the question once = you understand the principles. Andreas's advice to use a compiler is to he= lp you achieve that understanding. He did not suggest you use a compiler d= uring the test, but during your study. Of course you are allowed to use a = compiler when you are studying. Unlike member methods, member variables do not override inherited variables= . It is rarely if ever necessary, and I would say never desirable to refer= to a variable via the 'super.' notation. If the variable is inherited, th= en 'super.variable' is exactly the same as 'this.variable'; both syntaxes r= efer to the same variable. If a variable in the child class has the same n= ame as an inherited variable from an ancestor class, then you got problems.= It is not good to name the member variable the same as an inherited membe= r variable; the child variable "hides" the ancestor variable. So in the problem you showed us, the line=20 protected int var =3D 1; declares and initializes a member variable that is inherited by descendant = classes. ('protected' means the variable is accessible to child types and = to types in the same package.) So in the 'GrandChild' class, the 'main()' method: public static void main(String[] args) { GrandChild gc =3D new GrandChild(); gc.var =3D 2; Child c =3D new Child(); gc.test2(); } 'gc.test2()' and 'gc.var' refer to the same exact 'var' as 'super.var' beca= use there is no difference between 'this.var' and 'super.var' inside 'Grand= Child'. Notice that the 'Child' declaration, 'Child c =3D new Child();', creates an= unreferenced variable 'c'. Nothing uses 'c' - it's just allocated and gar= bage collected. The JVM very likely will not even allocate that object in = any run of the program. --=20 Lew