Thursday, January 8, 2009

Calling the overriden method

It seems that there is no way to call a sibling method.

Yesterday, I had just another conflict wich java forum dons. As usually, they insist that features not existent in the Java are "evil". They were proud remarking that they claim this without ever looking into my code. Once I asked to excuse me for ignoring their bigotry in the reply, they reported my post as expressing bad personal attitude and later removed the topic.

It is weired that even reflection returns the extended method when requested the method declared in the base calss!
class Base {

void method() {
System.out.println("method: call me!");
}

void anotherMethod() {
System.out.println("anotherMethod: I want to call the method above!");

Base.this.method();

try {
Method overriddenMethod = Base.class.getDeclaredMethod("method",
new Class[] {});
overriddenMethod.invoke(this, new Object[] {});
} catch (Exception e) {
e.printStackTrace();
}

}

}

class Extension extends Base {

void method() {
System.out.println("He-he-he. It's me, extended");
}

public static void main(String[] args) {
new Extension().anotherMethod();
}

}



It seems that the code is there but we cannot call it if the method is overriden. I have resolved the problem by declaring an additional method in the base. It contains the default implementation, which called both from the base method and anotherMethod. One mindfult person, however, presented the same idea, which means that it is the best we can do.

The bigots clamed that it is bad to invoke overriden code but refused to respond why then java allows super.method() to call it from the extended class. I have noted, however, that this defficiency is actually a strenght of Java taking two considerations
1) the feature is very rarely needed; and
2) can be very easily worked around.
If you remember, the Java spirit is to keep language simple. This means that rare features, wich can be easily implemented by existing java facilities must not be introduced into the language overcomplicating it. It is better to remove the complexity into the user program in this case. Optimization, efficiency, is a very good argument, which satisfies me. Unfortunately, these stupid idiots cannot understand it. They have no desire to see what is good and what is missing in Java. All they can is to put a stright jacket on the thinking people turinging us into obidient cattle.

Now, I recall that about 2 years ago they deleted my topic discussing why local classes are not visible in the routine before the thread reaches its declaration? The "dons" responded that the class does not exist before runtime creates it. They have removed my topic after I have mentioned that the classes are compiled in advance even before application is started and are loaded at JVM start up. Do they ever feel shame or act thoughtlessly? I have discovered that "in advance"visibility of local classes would make all the final variables visible througout the routine, even those not yet initialized ones.

No comments: