-
Enhancement
-
Resolution: Unresolved
-
P4
-
16
1. "Example 4.5.1-2. Bounded Wildcards" gives the example code
boolean addAll(Collection<? extends E> c)
and continues
An alternative would be to declare the method itself to be generic:
<T> boolean addAll(Collection<T> c)
Should the alternative be
<T extends E> boolean addAll(Collection<T> c)
where I changed "<T>" to "<T extends E>"? That seems more analogous.
If I am missing something, it might be nice to explain that in the text, to head off other questions like mine.
2. Non-normative text in section 5.1 says:
public static <T> void reverse(List<T> list)
This is undesirable, as it exposes implementation information to the caller.
It would be helpful to explain what implementation information that exposes to the caller, and how the caller could take advantage of it in an undesirable way. Also, the justification in section 5.1, "exposes implementation information", differs from the justification in Example 4.5.1-2 which says "In the absence of such interdependency, generic methods are considered bad style [because the type variable is used only once], and wildcards are preferred." It may be good to make the two sections of the JLS consistent by giving the same argument in both places: either "it's bad style" in both places, or "it exposes implementation details" in both places.
boolean addAll(Collection<? extends E> c)
and continues
An alternative would be to declare the method itself to be generic:
<T> boolean addAll(Collection<T> c)
Should the alternative be
<T extends E> boolean addAll(Collection<T> c)
where I changed "<T>" to "<T extends E>"? That seems more analogous.
If I am missing something, it might be nice to explain that in the text, to head off other questions like mine.
2. Non-normative text in section 5.1 says:
public static <T> void reverse(List<T> list)
This is undesirable, as it exposes implementation information to the caller.
It would be helpful to explain what implementation information that exposes to the caller, and how the caller could take advantage of it in an undesirable way. Also, the justification in section 5.1, "exposes implementation information", differs from the justification in Example 4.5.1-2 which says "In the absence of such interdependency, generic methods are considered bad style [because the type variable is used only once], and wildcards are preferred." It may be good to make the two sections of the JLS consistent by giving the same argument in both places: either "it's bad style" in both places, or "it exposes implementation details" in both places.