I'd previously typed up a big introduction and mentioned several minor terminology, subtle functionality or grammar details about stuff in chapters 1 or 2.
It took too long and I lost it.
So, long-long-time programmer, new to Java Certification, proud owner of both the Programmer I and II books for the 815 and 816 which have now congealed into the 819.
On page 97 in Chapter 3, we haven't really gotten to object equality and object equivalence yet, we are kind of foreshadowing it I think.
However, I take exception to the description of instanceof, which is as follows:
"a instanceof b
Returns true if the reference that a points to is an instance of a class, subclass or class that implements a particular interface, as named in b"
At first I was unhappy with the sentence because implementing a particular interface seemed to be applying to three different cases, i.e. that b always named an interface.
That made me read the sentence more carefully, and while I realized that only the third of the three cases names an interface (still confusingly worded there--I know it is in a table and spacing is tight), that the sentence now implies to me that the reference is what is being pointed to, or that the declared type of the reference itself determines the value returned by instanceof.
This is super-confusing because in some languages the reference itself has more power than in java, where once compile time is over, the actual object is king.
I think we talk more about instanceof later, I already know a bunch of interesting things about it, including when it will and when it won't even compile.
Whether it compiles or not obviously is determined statically at compile time.
So my complaints about this are:
1. I always use reference to refer to the references themselves, which are local variables or static or member variables, and not the objects to which they refer to on the heap, which I would always call the objects referred to (on the heap if I was beating the moose to death). Alternatively, the instances, but in a sentence like that I'd always say "object".
2. The part that originally confused me was the second part of the sentence, which I realize had terseness as a goal. It returns true if the object referred to by reference a is of class B or a subclass of B if B is a class, and if it implements interface B if B is an interface.
The "fun" parts of instanceof is understanding when it will and won't compile, which this book goes into later and I haven't gotten to. But I really got stuck on the wording in this brief intro to the operator.
I might prefer "Returns true if the object to which reference a points to is an instance of class b, or an instance of a subclass of b, if b is a class; or if the object is of a class that implements a particular interface, if b names an interface"
The fun tricky parts come later, but being aware of them (and coming from some languages where more runtime stuff depends on references than does in Java)
I love JavaRanch -- errr, or is it CodeRanch, wait, I think one is a subclass of the other, the book, and the authors. I just found those lines murky.
We don't often use instanceof in real programming; the one place its use is “respectable” is however, as you guessed, in the equals(java.lang.Object) method.
Maybe the quote from the book would be clearer with an extra comma.
Returns true if the reference that a points to is an instance of a class, subclass, or class that implements a particular interface, as named in b
In that sentence, take “or” as having a higher precedence than “as”. It means that the (class, subclass, or class implementing an interface) is as named in b.
And that sentence does use “reference” strictly; if the reference points to an instance of ..., then it points to an object. If a reference doesn't point to an instance, then it doesn't point to an object, then if the code compiles in the first place, the reference points to null, and in that case a instanceof b will evaluate to false. I am afraid that your version
Returns true if the object to which reference a points to is an instance of class b, or an instance of a subclass of b, if b is a class; or if the object is of a class that implements a particular interface, if b names an interface
doesn't completely take account of the possibility of the reference pointing to null, and therefore doesn't completely describe the behaviour of instanceof.
Gee, thanks! Altho I still find the original short version confusing if it is taken on its own, they go on to explain it in great depth a few pages later, and I think I am good. This exchange was valuable to me because I am now less likely to forget the important "what does instanceof do for null references?" ever on an exam. Uninitialized will fail to compile, value of null will just yell FALSE regardless of what is on the right side, as long as it compiles. Excellent, thanks again!