Adam Lally wrote:
> 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
I agree with Adam and Jukka. Even in our implementation code, it's
most of the time not a good idea to use CASImpl. We shouldn't encourage
clients to do so.
--Thilo
