Guava type inference problems

[Jonathan Ross]

Good catch Rémi, thanks for pointing that one out.  In defence of the
original author, the case at hand was a private method - the wildcard in
the return type was a probably a refactoring accident ;-)

Thanks for adding the bug report, Vicente.


On Thu, Nov 21, 2013 at 8:31 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 11/20/2013 12:37 AM, Jonathan Ross wrote:
> > Hello again,
> >
> > my problem below is probably also due to a well understood change to the
> > type inference rules, and I am sorry if this has all been said and done
> > before, but I really want to understand what's going on here.
> >
> > Paraphrasing some production 1.7 code using guava, I have essentially the
> > following:
> >
> > import java.util.Collection;
> > import java.util.List;
> >
> > abstract class TypeTest {
> >
> >      interface I {}
> >
> >      public Collection<? extends I> excludeFrom(Collection<? extends I>
> > include,
> >              Collection<? extends I> exclude) {
> >          return copyOf(filter(include, not(in(exclude))));
> >      }
>
> My comment will not solve your problem but returning a Foo<? extends
> Bar> or a Foo<? super Bar>
> is not a good idea because it forces the user code of excludeFrom to use
> wildcards too.
>
> The wildcard mechanism was introduced to enable API writers to write
> method signature that accept to be called using subtypes/supertypes of
> parametrized types that are declared by formal parameters of the method.
> So there is no point to use wildcards in a return type.
>
> Wildcards are tools for API writers and should not be used in code that
> use APIs.
>
> cheers,
> Rémi
>
>
>
> ________________________________
>
> The information in this e-mail is intended only for the person or entity
> to which it is addressed.
>
> It may contain confidential and /or privileged material. If someone other
> than the intended recipient should receive this e-mail, he / she shall not
> be entitled to read, disseminate, disclose or duplicate it.
>
> If you receive this e-mail unintentionally, please inform us immediately
> by "reply" and then delete it from your system. Although this information
> has been compiled with great care, neither IMC Financial Markets & Asset
> Management nor any of its related entities shall accept any responsibility
> for any errors, omissions or other inaccuracies in this information or for
> the consequences thereof, nor shall it be bound in any way by the contents
> of this e-mail or its attachments. In the event of incomplete or incorrect
> transmission, please return the e-mail to the sender and permanently delete
> this message and any attachments.
>
> Messages and attachments are scanned for all known viruses. Always scan
> attachments before opening them.
>