aspose file tools*
The moose likes Java in General and the fly likes Reason for not having dynmaic binding for instance variables Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Reason for not having dynmaic binding for instance variables" Watch "Reason for not having dynmaic binding for instance variables" New topic
Author

Reason for not having dynmaic binding for instance variables

Victor Ho
Ranch Hand

Joined: Sep 05, 2003
Posts: 74
Hi,

As we know, Java only does dynamic binding for methods but not for instance variables.
i.e.
class A {
protected int m_num = 10;
}
class B extends A {
protected int m_num = 20;
}
A obj = new B();
obj.m_var --> 10

Does anyone know why it is designed as such? I believe the same language design decision is for C++ where you can only declare virtual functions.
slade cox
Greenhorn

Joined: Sep 07, 2002
Posts: 14
The reason your subclass's variable does not behave like an overriden function is that you have declared the variable twice, thus creating two separate variables with the same name (generally not a good idea). The member variable for class A is used when an object is cast as A. If you actually want to change the original variable for all instances of subclass B then you should do this:

class A {
protected int m_num = 10;
}
class B extends A {
B() { m_num=20; }
}
A obj = new B();
obj.m_var --> 20

Then there is only one variable named m_num, and no confusion.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Can you provide a *real* example of where it might be of value to have dynamic binding of variables???


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Victor Ho
Ranch Hand

Joined: Sep 05, 2003
Posts: 74
I think there are actually 2 issues.

1) If for whatever reasons (could be by mistake) that a program has a subclass that overrides an instance variable of its parent's (declared with same name and type), I think it is still more desirable to access the data from the real object.
e.g.
public abstract class Vechicle {
// common attribues that are not initizlied in abstract class
protected int m_maxspeed;
}
public class Van extends Vechicle {
protected int m_maxspeed = 100;
}
Vechicle v = new Van();
int result = v.maxspeed + 20; // don't want an uninitialized value here

2) I actually think there is not much "real" value to override an instance variable which just creates another storage.

So, my doubt is that if overriding of instance variables is allowed, why not make it dynamically binded? (all b/c it has more performance overhead?)
OR why not disallow overriding of instance variables altogether?
slade cox
Greenhorn

Joined: Sep 07, 2002
Posts: 14
As for your issue 1) you bring up a good point that an accidental shadowing of a parent class's member variable could produce unexpected results. This is why it's always best to avoid shadowing variables. In fact, better compilers like jikes will warn you if you attempt to do so. Anyone using a compiler that doesn't issue such warnings should make sure to be familiar with the parent classes public and its protected instance variables.

Regarding issue 2) I would ask you this, how else would you access the parent class's member variable if it was completetly overriden by the subclass? ie. if you had an instance of class B above, how could one access the original m_num if casting it to class A still gave you class B's member variable?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Reason for not having dynmaic binding for instance variables
 
Similar Threads
late binding
Shadowed static variable
Are my answers correct ?
Protected variables ONLY viewable to sub classes
protected doubt