assigning up the hierarchy
I was reading following lines from link
http://www.jchq.net/certkey/0501certkey.htm
did not understand it clearly.
Object references can be assigned up the hierarchy from child to base.
The following example illustrates how you can cast an object reference up the hierarchy
class Base{}
public class ObRef extends Base{
public static void main(String argv[]){
ObRef o = new ObRef();
Base b = new Base();
b=o;//This will compile OK
/*o=b; This would cause an error indicating
an explicit cast is needed to cast Base
to ObRef */
}
}
I did not understand why b=o is ok where as o=b is not ok without casting.
Any ideas, resources,sample code,links, highly appreciated. thanks in advance.
http://www.jchq.net/certkey/0501certkey.htm
did not understand it clearly.
Object references can be assigned up the hierarchy from child to base.
The following example illustrates how you can cast an object reference up the hierarchy
class Base{}
public class ObRef extends Base{
public static void main(String argv[]){
ObRef o = new ObRef();
Base b = new Base();
b=o;//This will compile OK
/*o=b; This would cause an error indicating
an explicit cast is needed to cast Base
to ObRef */
}
}
I did not understand why b=o is ok where as o=b is not ok without casting.
Any ideas, resources,sample code,links, highly appreciated. thanks in advance.
ASKER
>>> Any method, or variable, that would be accessible in a Base class will also be accessible and
when you mention
"available in an ObRef class" you mean
"available to a Base reference through aObRef object"?
please advise
.
when you mention
"available in an ObRef class" you mean
"available to a Base reference through aObRef object"?
please advise
.
HMmm. The question in Java is whether instructions given can be carried out or not. If you have a Base reference (b) to a class that is actually an ObRef class, there can be no problems. Any method call that is valid for a Base object will also be valid for an ObRef object. An ObRef object has all the methods of the Base object it was derived from available, as well as all the variables. So no problem can possibly ensue from such an assignment up the hierarchy.
Imagine, for instance, that the Base class defines a public method foo. Now you have reference Base b, as in the above example, and suppose you code the line:
b.foo();
If b refers to a Base object this can execute, because foo is a method defined in Base.
If b refers to an ObRef object this can also execute, because foo is a method defined in Base, which is an ancestor of ObRef, so it has access to all the Base methods.
Imagine, for instance, that the Base class defines a public method foo. Now you have reference Base b, as in the above example, and suppose you code the line:
b.foo();
If b refers to a Base object this can execute, because foo is a method defined in Base.
If b refers to an ObRef object this can also execute, because foo is a method defined in Base, which is an ancestor of ObRef, so it has access to all the Base methods.
ASKER
>>> So no problem can possibly ensue from such an assignment up the hierarchy.
assigning up means you mean right to left right(i mean right side of the equal towards left side of equal
Base b = new ObRef(); then that is assigning up the hierarchy right).
is it analogous to following program where you need explicit casting in case of primitives
public class Mc{
public static void main(String argv[]){
byte b=0;
int i = 5000;
b = (byte) i;
System.out.println(b);
}
}
please advise
assigning up means you mean right to left right(i mean right side of the equal towards left side of equal
Base b = new ObRef(); then that is assigning up the hierarchy right).
is it analogous to following program where you need explicit casting in case of primitives
public class Mc{
public static void main(String argv[]){
byte b=0;
int i = 5000;
b = (byte) i;
System.out.println(b);
}
}
please advise
>assigning up means you mean right to left right(i mean right side of the equal towards left side of equal
Yes. Though we usually think of the hierarchy with a base class at the "top", and derived classes "below" it. Hence the terminology of assigning "up" the hierarchy. To put it another way, assigning *up* the hierarchy means you can assign an object to a reference of an *ancestor* (which is shown closer to the top of the class hierarchy).
>is it analogous to following program where you need explicit casting in case of primitives
Hmm. I wouldn't think so. When casting from one primitive to another, there is certainly no question of one of them being derived from another.
When assigning "up" the hierarchy no cast is needed; it is safe by definition. "Base b=new ObRef();"
One could argue that assigning to a "wider" primitive is similar in that it is inherently safe and so no cast is needed: "i=b;" needs no cast.
When assigning "down" the hierarchy a cast is necessary so that the JVM will check the object at runtime: "ObRef o=(ObRef)b;" This will only succeed if b references an ObRef object, or something derived from it. If b references a Base obect the JVM will throw an Exception.
One could argue that this is kind of like assigning to a "narrower" primitive, in that, in that case, a cast is also needed. The cast shows that the coder explicitly acknowledges that precision *might* be lost:
b=(byte)i; (But note that the JVM will not throw an Exception in any circumstance here).
Yes. Though we usually think of the hierarchy with a base class at the "top", and derived classes "below" it. Hence the terminology of assigning "up" the hierarchy. To put it another way, assigning *up* the hierarchy means you can assign an object to a reference of an *ancestor* (which is shown closer to the top of the class hierarchy).
>is it analogous to following program where you need explicit casting in case of primitives
Hmm. I wouldn't think so. When casting from one primitive to another, there is certainly no question of one of them being derived from another.
When assigning "up" the hierarchy no cast is needed; it is safe by definition. "Base b=new ObRef();"
One could argue that assigning to a "wider" primitive is similar in that it is inherently safe and so no cast is needed: "i=b;" needs no cast.
When assigning "down" the hierarchy a cast is necessary so that the JVM will check the object at runtime: "ObRef o=(ObRef)b;" This will only succeed if b references an ObRef object, or something derived from it. If b references a Base obect the JVM will throw an Exception.
One could argue that this is kind of like assigning to a "narrower" primitive, in that, in that case, a cast is also needed. The cast shows that the coder explicitly acknowledges that precision *might* be lost:
b=(byte)i; (But note that the JVM will not throw an Exception in any circumstance here).
ASKER
you are riggt. when i say
b = i;
it said compile time error like cannot convert int to byte not runtime classcastexception etc
b = i;
it said compile time error like cannot convert int to byte not runtime classcastexception etc
Has the question been answered?
If so, it is time to select one (or more) answers and grade them.
If not, perhaps a clarifying question would help.
If so, it is time to select one (or more) answers and grade them.
If not, perhaps a clarifying question would help.
ASKER
>>>b=(byte)i; (But note that the JVM will not throw an Exception in any circumstance here).
does JVM throw an Exception in case of
ObRef o=(ObRef)b
>>>
If b refers to an ObRef object this can also execute, because foo is a method defined in Base, which is an ancestor of ObRef, so it has access to all the Base methods.
b refers to an ObRef object means you are referring right hand side part right
like
Base b=new ObRef(); not the object variable reference type right?
Also if you override foo() method in ObRef class
when you call
b.foo()
calls the method on ObRef class right.
please advise
does JVM throw an Exception in case of
ObRef o=(ObRef)b
>>>
If b refers to an ObRef object this can also execute, because foo is a method defined in Base, which is an ancestor of ObRef, so it has access to all the Base methods.
b refers to an ObRef object means you are referring right hand side part right
like
Base b=new ObRef(); not the object variable reference type right?
Also if you override foo() method in ObRef class
when you call
b.foo()
calls the method on ObRef class right.
please advise
>b refers to an ObRef object means you are referring right hand side part right
I think you're trying to verify what I mean when I write "b refers to an ObRef object".
If so, then yes, I mean that b (the variable on the right of the assignment) refers to, that is "points to", an object that is, in fact, an ObRef object.
>Base b=new ObRef(); not the object variable reference type right?
And yes, such an assignment would bring that situation about. The result of that assignment is that b (even though it is type Base) refers to an object of type ObRef.
>Also if you override foo() method in ObRef class when you call b.foo() calls the method on ObRef class right.
Correct. Java knows the actual type of the object being referred to, and will operate on that basis. So, even though b is of type Base, the object being referred to is actually an ObRef object, and so the call to the foo method will be made w.r.t. an ObRef object. So if ObRef overrides the foo method, then b.foo() will call the foo method in the ObRef class, even though b is of type Base.
I think you're trying to verify what I mean when I write "b refers to an ObRef object".
If so, then yes, I mean that b (the variable on the right of the assignment) refers to, that is "points to", an object that is, in fact, an ObRef object.
>Base b=new ObRef(); not the object variable reference type right?
And yes, such an assignment would bring that situation about. The result of that assignment is that b (even though it is type Base) refers to an object of type ObRef.
>Also if you override foo() method in ObRef class when you call b.foo() calls the method on ObRef class right.
Correct. Java knows the actual type of the object being referred to, and will operate on that basis. So, even though b is of type Base, the object being referred to is actually an ObRef object, and so the call to the foo method will be made w.r.t. an ObRef object. So if ObRef overrides the foo method, then b.foo() will call the foo method in the ObRef class, even though b is of type Base.
ASKER
>>Correct. Java knows the actual type of the object being referred to, and will operate on that basis. So, even though b is of type Base, the object being referred to is actually an ObRef object, and so the call to the foo method will be made w.r.t. an ObRef object. So if ObRef overrides the foo method, then b.foo() will call the foo method in the ObRef class, even though b is of type Base.
with variable properties it is not same as with methods right. even if we override parent class variable property called in this case right. please advise
with variable properties it is not same as with methods right. even if we override parent class variable property called in this case right. please advise
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
However, the reverse is not true. An ObRef class can implement additional methods and/or variables that are *not* part of a Base class. Therefore, the compiler will not allow a Base object to be assigned to an ObRef refererence. An ObRef reference could be called upon to execute a method (or reference a variable) that a Base object does not have.
The assignment *can* be compiled if an explicit cast is added (o=(ObRef)b;). In this case the compiler will add a runtime check to the code. Then, when the code is being executed, and the cast occurs, the code will determine whether the object that b references is, in fact, a Base class or an ObRef or something different. It will allow the cast according to the same rules as the compiler (can go up the hierarchy, but not down); it's just applied at a later time.