Childchild= childList.get(0); // No! It's not a child! Type safety is broken...
Значение List<? extends Parent> заключается в том, что "Это список некоторого типа, который расширяется" Parent. Мы не знаем, какой тип - это может быть a List<Parent>, a List<Child> или a List<GrandChild>." Это позволяет безопасно извлекать любые элементы изList<T> API и преобразовывать из T в Parent, но небезопасно вызывать вList<T> API преобразование из Parent в T... потому что это преобразование может быть недопустимым.
Ответ 2
List<? super Parent>
PECS - "Производитель - расширяет, потребитель - превосходит". Ваш List является потребителем Parent объектов.
Ответ 3
Вот мое понимание.
Предположим, у нас есть универсальный тип с 2 методами
type L<T> T get(); voidset(T);
Предположим, у нас есть супертип P, и у него есть подтипы C1, C2 ... Cn. (для удобства мы говорим, что P является подтипом самого себя, и на самом деле является одним из Ci)
Теперь у нас также есть n конкретных типов L<C1>, L<C2> ... L<Cn>, как если бы мы написали n типов вручную:
type L_Ci_ Ci get(); voidset(Ci);
Нам не нужно было писать их вручную, вот в чем суть. Между этими типами нет никаких связей
L<Ci> oi = ...; L<Cj> oj = oi; // doesn't compile. L<Ci> and L<Cj> are not compatible types.
For C++ template, that's the end of story. It's basically macro expansion - based on one "template" class, it generates many concrete classes, with no type relations among them.
For Java, there's more. We also got a type L<? extends P>, it is a super type of any L<Ci>
L<Ci> oi = ...; L<? extendsP> o = oi; // ok, assign subtype to supertype
What kind of method should exist in L<? extends P>? As a super type, any of its methods must be hornored by its subtypes. This method would work:
type L<? extendsP> P get();
because in any of its subtype L<Ci>, there's a method Ci get(), which is compatible with P get() - the overriding method has the same signature and covariant return type.
This can't work for set() though - we cannot find a type X, so that void set(X) can be overridden by void set(Ci) for any Ci. Therefore set() method doesn't exist in L<? extends P>.
Also there's a L<? super P> which goes the other way. It has set(P), but no get(). If Si is a super type of P, L<? super P> is a super type of L<Si>.
type L<? super P> voidset(P);
type L<Si> Si get(); voidset(Si);
set(Si) "overrides" set(P) not in the usual sense, but compiler can see that any valid invocation on set(P) is a valid invocation on set(Si)
Ответ 4
This is because of "capture conversion" that happens here.
Every time the compiler will see a wildcard type - it will replace that by a "capture" (seen in compiler errors as CAP#1), thus:
List<? extendsParent> list
will become List<CAP#1> where CAP#1 <: Parent, where the notation <: means subtype ofParent (also Parent <: Parent).
java-12 compiler, when you do something like below, shows this in action:
List<? extendsParent> list = newArrayList<>(); list.add(newParent());
Among the error message you will see:
..... CAP#1extendsParent from capture of ? extendsParent .....
When you retrieve something from list, you can only assign that to a Parent. If, theoretically, java language would allow to declare this CAP#1, you could assign list.get(0) to that, but that is not allowed. Because CAP#1 is a subtype of Parent, assigning a virtual CAP#1, that list produces, to a Parent (the super type) is more that OK. It's like doing:
Strings="s"; CharSequences= s; // assign to the super type
Now, why you can't do list.set(0, p)? Your list, remember, is of type CAP#1 and you are trying to add a Parent to a List<CAP#1>; that is you are trying to add super type to a List of subtypes, that can't work.