super.super.super how?

[sanjay manohar]

I'm sure I read that the following syntax can be used.

class A{public boolean member(){return true;}}
class B extends A{public boolean member(){return false;}}
class C extends B{
void test(){
this.A.member(); //call the ORIGINAL member
this.B.member(); //call the super.member
member(); //call this.member
}
public boolean member(){return false;}
}

refers to the member

 

[John C. Bollinger]

I'm sure I read that the following syntax can be used.

class A{public boolean member(){return true;}}
class B extends A{public boolean member(){return false;}}
class C extends B{
void test(){
this.A.member(); //call the ORIGINAL member
this.B.member(); //call the super.member
member(); //call this.member
}
public boolean member(){return false;}
}

refers to the member

No. The syntax you show is used to access methods of a containing class
that are hidden by like-named methods of its inner classes (from inside
the inner class). This is a completely different thing from accessing
members of superclasses.

 

[Joona I Palaste]

Whow! What a problem!

class A
class B extends A
class C extends B

How can I access "A" members from class "C"?

super.super.a_base_class_member();
is not working...

I believe its too much, if I cannot have such access...
I think, I have miss something here. (In C++ its too easy)

This can't be done, as has been already said, and shouldn't be done.
A class decides for itself which methods it implements in which way.
If "super.super" worked, subclasses could circumvent this and gain
access to methods that the class explicitly chose to override with its
own versions.

 

[Anthony Borla]

I forgot!

a_base_class_member()
is implemented in both "A", "B", "C" classes.

Other posters have explained that this cannot be done. The reason for this -
purely from an OO perspective - is that it would be a violation of the
Liskov Substitution Principle which basically states that a subclass must be
substitutable for its superclass [Google for more information on this]. This
is one of the underpinings of OO, and, as such, is respected / enforced by
the Java language.

When you do this:

class B extends A { ... }

you are creating a new class - class B - that promises to behave just like
class A in situations where a class A type object is expected.

When you do this:

class C extends B { ... }

you are creating a new class - class C - that promises to behave just like
class B in
situations where a class B type object is expected.

Allowing class C to bypass class' B behaviour by adopting class' A behaviour
is tantamount to breaking the promise that it will behave like class B, and
thus, cannot be allowed to happen.

Taking a more practical viewpoint, a method that was defined in class A, and
was then overridden in class B *cannot be allowed* to be invoked directly by
class C because this would be bypassing the overridden code in class B.

If you need one or more methods to be freely accessable by subclasses, or
sub-subclasses etc, then implement 'protected' or maybe package-level access
methods that are not overridden. If you need similar functionality at
several class levels then perhaps they could be named so the class they
belong to is identified. Example:

class A
{
...
protected void classA_MethdX() { ... }
...
}

class B extends A
{
...
protected void classB_MethodX() { ... }
...
}

class C extends B
{
...
protected void classC_MethodX() { ... }
...
}

I hope this helps.

Anthony Borla

 

[Darryl Pierce]

I'm sure I read that the following syntax can be used.

Nope. That's how an inner class accesses aspects of it's container
class. Did you actually try this before posting?