Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8131 > unrolled thread

super

Back to article view | Back to comp.lang.java.programmer

Contents

  super "giuseppe.on.usenet" <giuseppe.on.usenet@gmail.com> - 2011-09-18 09:53 -0700
    Re: super Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-09-18 12:39 -0500
      Re: super Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-18 18:26 +0000
        Re: super Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-18 18:29 +0000
        Re: super "giuseppe.on.usenet" <giuseppe.on.usenet@gmail.com> - 2011-09-18 12:21 -0700
          Re: super Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-18 19:48 +0000
            Re: super Lew <lewbloch@gmail.com> - 2011-09-18 13:16 -0700

#8131 — super

/* file: ~/dir1/Parent.java */
package dir1;
public class Parent {
    protected int var = 1;
}
/* end Parent.java */

/* file: ~/dir2/Child.java */
package dir2;
import dir1.Parent;
class Child extends Parent {
    public void test() {
        System.out.println("var is " + var);
    }

    public static void main(String[] args) {
      Child c = new Child();
      c.test();
    }
}
/* end Child.java */

/* file: ~/dir2/GrandChild.java */
package dir2;
public class GrandChild extends Child {
    public void test2() {
        System.out.println("super.var is " + super.var);
        System.out.println("var is " + var);
    }

    public static void main(String[] args) {
        GrandChild gc = new GrandChild();
        gc.var = 2;
        Child c = new Child();
        gc.test2();
    }
}
/* end GrandChild.java */

When I run dir2.Child, I get:
var is 1
which is what I was expecting.
When I run dir2.GrandChild, I get:
super.var is 2
var is 2
These last two variables have the same value, although I only modified
gc.var in GrandChild.java. Why?
Thank you.

[toc] | [next] | [standalone]

#8132

On 9/18/2011 11:53 AM, giuseppe.on.usenet wrote:
> When I run dir2.Child, I get:
> var is 1
> which is what I was expecting.
> When I run dir2.GrandChild, I get:
> super.var is 2
> var is 2
> These last two variables have the same value, although I only modified
> gc.var in GrandChild.java. Why?

How many times did you declare a variable named `var'? By my count, you 
defined it once, so `var' and `super.var' both refer to the same 
variable `var', namely the one defined in Parent.


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#8133

Joshua Cranmer <Pidgeot18@verizon.invalid> wrote:
> On 9/18/2011 11:53 AM, giuseppe.on.usenet wrote:
>> When I run dir2.Child, I get:
>> var is 1
>> which is what I was expecting.
>> When I run dir2.GrandChild, I get:
>> super.var is 2
>> var is 2
>> These last two variables have the same value, although I only modified
>> gc.var in GrandChild.java. Why?
> How many times did you declare a variable named `var'? By my count, you 
> defined it once, so `var' and `super.var' both refer to the same 
> variable `var', namely the one defined in Parent.

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.  Recompile & run it.  You'll
see that instantiating class Child (or not doing it) doesn't change
anything. What does this tell you?

[toc] | [prev] | [next] | [standalone]

#8134

Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote:
> Joshua Cranmer <Pidgeot18@verizon.invalid> wrote:
>> On 9/18/2011 11:53 AM, giuseppe.on.usenet wrote:
>>> When I run dir2.Child, I get:
>>> var is 1
>>> which is what I was expecting.
>>> When I run dir2.GrandChild, I get:
>>> super.var is 2
>>> var is 2
>>> These last two variables have the same value, although I only modified
>>> gc.var in GrandChild.java. Why?
>> How many times did you declare a variable named `var'? By my count, you 
>> defined it once, so `var' and `super.var' both refer to the same 
>> variable `var', namely the one defined in Parent.
>
> 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.  Recompile & run it.  You'll
> see that instantiating class Child (or not doing it) doesn't change
> anything. What does this tell you?

Alternatively, leave the line "Child c = new Child();" in, and rather
add another line "c.test()" to the end of GrandChild's main method.

[toc] | [prev] | [next] | [standalone]

#8135

On 18 Set, 20:26, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
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.  Recompile & run it.  You'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?). Maybe
they instantiated the Child object just to try to confuse the reader.
Actually, I don't think the question was very simple, because you are
not supposed to use a compiler during the exam.

[toc] | [prev] | [next] | [standalone]

#8136

giuseppe.on.usenet <giuseppe.on.usenet@gmail.com> wrote:
> On 18 Set, 20:26, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
> 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.  Recompile & run it.  You'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?).

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.

> Maybe
> they instantiated the Child object just to try to confuse the reader.

Not primarily to confuse him, but rather to test his confusability ;-)

[toc] | [prev] | [next] | [standalone]

#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.  Recompile & run it.  You'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?).
> 
> 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.
> 
>> Maybe
>> they instantiated the Child object just to try to confuse the reader.
> 
> Not primarily to confuse him, but rather to test his confusability ;-)

Andreas is completely correct, giuseppe.  It's a test question, so of course 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 help you achieve that understanding.  He did not suggest you use a compiler during 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, then 'super.variable' is exactly the same as 'this.variable'; both syntaxes refer to the same variable.  If a variable in the child class has the same name 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 member variable; the child variable "hides" the ancestor variable.
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.3>

So in the problem you showed us, the line 

   protected int var = 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 = new GrandChild();
   gc.var = 2;
   Child c = new Child();
   gc.test2();
 }

'gc.test2()' and 'gc.var' refer to the same exact 'var' as 'super.var' because there is no difference between 'this.var' and 'super.var' inside 'GrandChild'.

Notice that the 'Child' declaration, 'Child c = new Child();', creates an unreferenced variable 'c'.  Nothing uses 'c' - it's just allocated and garbage collected.  The JVM very likely will not even allocate that object in any run of the program.

-- 
Lew

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web