commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [collections] generics issues
Date Tue, 30 Apr 2013 23:29:04 GMT
I believe the point to this one is that any Closure that accepts a
supertype of T can accept a T argument, so it should be safe to "pretend"
that the Closure is actually parameterized to accept a T argument.

Matt


On Tue, Apr 30, 2013 at 6:12 PM, sebb <sebbaz@gmail.com> wrote:

> On 30 April 2013 22:15, Thomas Neidhart <thomas.neidhart@gmail.com> wrote:
>
> > On 04/30/2013 11:09 PM, sebb wrote:
> > > On 30 April 2013 21:54, Thomas Neidhart <thomas.neidhart@gmail.com>
> > wrote:
> > >
> > >> On 04/30/2013 10:49 PM, sebb wrote:
> > >>> I've just been looking at fixing generics warnings in the test code.
> > >>>
> > >>> There are no current warnings in the main code.
> > >>>
> > >>> However, I've just discovered that this is because the warnings have
> > been
> > >>> suppressed, regardless of whether that is justified or not.
> > >>>
> > >>> I think this needs to be fixed before a release; it's quite likely
> that
> > >>> some API changes will be needed. In turn these may change the test
> > code.
> > >>>
> > >>
> > >> Well, we have to look at them case by case
> > >
> > >
> > > Yes.
> > >
> > >
> > >> I did not add a single
> > >> SuppressWarning so far myself).
> > >
> > >
> > > Me neither.
> > >
> > >
> > >> Most of them are needed because of casts
> > >> from Object to the actual generic type, e.g. when doing a clone.
> > >>
> > >> Perhaps, but I must admit I don't understand some of them.
> > >
> > > For example in FunctorUtils:
> > >
> > >     static <T> Closure<T> coerce(final Closure<? super T>
closure){
> > >         return (Closure<T>) closure;
> > >     }
> > >
> > > If the closure parameter is not of type T, surely the cast is bound to
> > fail?
> > > So why use <? super T> ?
> >
> > I think this is correct, and sometimes needed to overcome the wildcard
> > madness
>
>
> In other words: don't know for sure.
>
> If we are sure that the warning is misleading - and cannot be avoided -
> then we should use @SuppressWarnings with a comment to say why it's OK to
> ignore the warning. Otherwise the warning should stand until it can be
> fixed or safely ignored.
>
>
> > (and it is in the package private FunctorUtils).
> >
> >
> Does not matter; it's main code and can still cause unexpected crashes if
> the assumptions are wrong.
>
>
> > Thomas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message