On Sat, Aug 8, 2009 at 4:57 PM, Marshall Schor<m...@schor.com> wrote:
> Jörn Kottmann wrote:
>>
>> On Aug 7, 2009, at 8:57 PM, Marshall Schor wrote:
>>
>>> getViewIterator in CASImpl is written with the signature:
>>> Iterator<CAS> getViewIterator()
>>>
>>> If you are working with things needing CASImpl objects, you would write:
>>>
>>> Iterator<CAS> s = aCas.getViewIterator();
>>> while (s.hasNext()) {
>>> CASImpl ci = (CASImpl) s.next();
>>> ... code using ci...
>>> }
>>>
>>> If we changed the signature to:
>>> Iterator<T extends CAS> getViewIterator()
>>> then you would write:
>>> Iterator<CASImpl> s = aCas.getViewIterator(); // cast done inside the
>>> support code, not here
>>> while (s.hasNext()) {
>>> CASImpl ci = s.next(); // works OK without casting
>>> ... code using ci...
>>> }
>>>
>>> Would it be better to have that form of the signature?
>>
>> +1, though did not know that its possible, we should check other
>> places too
>
> +1 to checking other places :-)
>
> The tutorial on generics by Gilad Bracha,
> http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf, on page 20 near
> the top says:
>
>> In general, if you have an API that only uses a type parameter T as an
>> argument, its
>> uses should take advantage of lower bounded wildcards (? super T).
>> Conversely, if
>> the API only returns T, you’ll give your clients more flexibility by
>> using upper bounded
>> wildcards (? extends T).
>
> There are many cases I think in our generification where the 2nd part of
> this, returning XXX<? extends T> or a variant, is a better choice.
>
I must say I don't understand why returning something like List<?
extends CAS> is an improvement. Is this supposed to mean that the
client could specify ANY subtype of CAS and it's supposed to work? So
someone could write:
class MyCas implements CAS {...}
List<MyCas> result = aCAS.getViewIterator()
Which couldn't possibly work. I guess it would compile but generate a
ClassCastException at runtime. Is that a good thing?
I found an expert with a differing point of view from your expert:
http://www.ibm.com/developerworks/java/library/j-jtp07018.html?S_TACT=105AGX02&S_CMP=EDU
"Keep bounded wildcards out of return values
It is sometimes tempting to use a bounded wildcard in the return type
of a method. But this temptation is best avoided because returning
bounded wildcards tends to "pollute" client code. If a method were to
return a Box<? extends T>, then the type of the variable receiving the
return value would have to be Box<? extends T>, which pushes the
burden of dealing with bounded wildcards on your callers. Bounded
wildcards work best when they are used in APIs, not in client code."
-Adam
