Enthuware

Hi,
I don't understand how using the cast in line #4 "takes advantage of generics". I thought one of the points of *typed* generics was that they enable you (amongst other things) to not have to use casts. We are told, you shouldn't use casts unless you have to. By typing a collection you don't have to use casts.
If you type the Map/HashMap, (e.g. Map<K,V>) rather than using a raw Map/HashMap, then map.get(key) will return a V. Therefore you don't need to cast to V. In the case of the question, by typing hte HashMap to <Book,Integer> you can use Integer i = map.get(key).
By leaving the cast in, you're not taking advantage of typed generics. Or am I wrong?
Thanks.

Using the cast is certainly not "taking an advantage of generics". Where does the question or the option say that it is?

-Paul.

That's my point. The existing code uses a cast. I selected the option to remove the cast, because by typing a collection (i.e. not using a raw collection) you're asserting that the methods return an object of a specific type. The cast is hence superfluous. But, the option to remove the cast is marked incorrect. So, what gives?

I see now what you mean. The question asks you to choose changes that are absolutely necessary to take advantage of generics.

So to take advantage of generics you need to use generics in Map declaration. Without this change, you can't take advantage of generics.

Whether you are actually taking advantage of the generic declaration is a separate thing. It is true that by keeping the cast, you are not taking advantage of the generic map declaration, but that is not what is asked by the question. The question only asks you what you absolutely must do to take advantage of generics.

HTH,
Paul.

Ok thanks.

Very Sneaky question again, the goal of generics is to avoid casting, but i agree it is not "absolutely" needed....
I sometime wonder if im not wasting my time studying this exam ....

The explanation "This change is fine if coupled with option 2 but it is not required" misses a change from the original #5. To wit, the code explained returns an Integer.


Now, the original #5 returns a primitive int.

Perhaps instead of "fine", the explanation should riff off the existing text from another question - "will break existing code that depends on the fact that this method return an int (instead of Integer)."

bluster wrote:The explanation "This change is fine if coupled with option 2 but it is not required" misses a change from the original #5. To wit, the code explained

Code: Select all

Integer i = map.get(b); 
return i == null? 0:i;

returns an Integer.


Now, the original #5

Code: Select all

return i == null? 0:i.intValue();  //5

returns a primitive int.

Perhaps instead of "fine", the explanation should riff off the existing text from another question - "will break existing code that depends on the fact that this method return an int (instead of Integer)."

The given explanation is correct. It doesn't break any existing code. It is ok to return Integer object if the return type of the method is int because Integer will automatically be unwrapped to an int.

HTH,
Paul.