Forums Register Login

instanceof

+Pie Number of slices to send: Send

consider the code line:
interface Face { }
class Bar implements Face{ }
class Foo extends Bar { }

based on this the following table is constructed( k& s book pg-286,operators)




First Operand instanceof operand(comparing reference) Result after instanceof is performed
(Reference Being Tested)
null Any class or interface type false
Foo instance Foo, Bar, Face, Object true
Bar instance Bar, Face, Object true
Bar instance Foo false
Foo [ ] Foo, Bar, Face false
Foo [ ] Object true
Foo [ 1 ] Foo, Bar, Face, Object true

here i have the doubt regarding the relation between Foo[] and FOo,bar,Face which gives an false on instanceof operation between them and Foo[1] and foo,bar,face,Object instanceof relation gives true result how is this possible !! what is the difference between foo[] and foo[1];

+Pie Number of slices to send: Send
 

vijay umar wrote:
here i have the doubt regarding the relation between Foo[] and FOo,bar,Face which gives an false on instanceof operation between them and Foo[1] and foo,bar,face,Object instanceof relation gives true result how is this possible !! what is the difference between foo[] and foo[1];


foo[] is an array object, not a foo object. foo[1] is a foo object.
+Pie Number of slices to send: Send
but where do we declare an object like foo[1]....

i thought it is an array element... isnt it!
+Pie Number of slices to send: Send
IMHO trying to compile Foo[] instanceof Foo (or Bar, of Face) should give compile time error, something like inconvertible types, am I wrong???
+Pie Number of slices to send: Send
 

Alexander Danilou wrote:IMHO trying to compile Foo[] instanceof Foo (or Bar, of Face) should give compile time error, something like inconvertible types, am I wrong???


No, you are right. They are not in the same inheritance tree, so the compiler can see the error.

but where do we declare an object like foo[1]....
i thought it is an array element... isnt it!


Yes, it is an array element, which is foo. Every element in the array foo[] is of type foo (or a subtype).

Some code example:
+Pie Number of slices to send: Send
That means array object of a class is different from the actual object of a class!! isnt it
+Pie Number of slices to send: Send
 

vijay umar wrote:That means array object of a class is different from the actual object of a class!! isnt it


Yes. They even don't share the same inheritance tree. So if you compare them with then instanceof operator, you get a compiler error.

cheers
Bob
+Pie Number of slices to send: Send
ok! thanks a lot bob!
+Pie Number of slices to send: Send
 

Bob Wheeler wrote:

vijay umar wrote:That means array object of a class is different from the actual object of a class!! isnt it


Yes. They even don't share the same inheritance tree. So if you compare them with then instanceof operator, you get a compiler error.

cheers
Bob



If instanceOf detects that you have tested dog to be cat, and they are not related inheritance wise, why give a compiler error, why not just say false!?

Thanks
+Pie Number of slices to send: Send
From the JLS

If a cast of the RelationalExpression (the left operand of instanceof) to the ReferenceType (the right operand of instanceof) would be rejected as a compile-time error, then the instanceof relational expression likewise produces a compile-time error.



So since Cat and Dog (which is by the way nowhere in this thread) are not compatible, then instanceof comparison will fail at compile time...
+Pie Number of slices to send: Send
thanks Ankit
a guess we're saying - that's the spec', that's how it is -- as opposed to why
+Pie Number of slices to send: Send
 

Nigel Shrin wrote:a guess we're saying - that's the spec', that's how it is -- as opposed to why



No, that's not the case. Lets take an example



Now if you try an instanceof comparison between these, it will fail. The reason being, it can never be true. Then what's the use of allowing such thing. You can't do a cast, neither anything else. So allowing this is useless and wastage of developers efforts and might result in a bug later on (obviously if you are doing such a test, then you've done something wrong as this test will always be false so its wrong)...
+Pie Number of slices to send: Send
with instanceOf you have three possible results:
1) True - is current object type or a parent/ancestor class
2) False - if in the tree but beneath
3) Compile error if outside inheritance tree

So my question of why not return False if outside the tree, would encompass both the last two scenarios - a false could be a valid branch to other code.

So you would have to use a try/catch if there is a risk of a compile error? / or you should not be asking the question!!!
+Pie Number of slices to send: Send

Hey Nigel,

I think, giving the compilation error when objects are in different inheritance tree make more sense, reason being a developer should use instance of operator only when he can not determine the type of object at the time of coding. I guess an intelligent developer would never try to check something in runtime which he already know at design time itself.

Regards
Salil Verma
A wop bop a lu bop a womp bam boom! Tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1645 times.
Similar Threads
instanceof operand
instanceof
Doubt: K&B 1.5 p. 286; table 4-1 (� instanceof�)
SCJP ::: chapter 4 p.no 286 instanceof ..........
instanceOf explanation needed
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 06:37:17.