Re: [collections] generics issues

[sebb <se...@gmail.com>]

On 30 April 2013 22:15, Thomas Neidhart <th...@gmail.com> wrote:

> On 04/30/2013 11:09 PM, sebb wrote:
> > On 30 April 2013 21:54, Thomas Neidhart <th...@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
>
>

Re: [collections] generics issues

[Matt Benson <gu...@gmail.com>]

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 <se...@gmail.com> wrote:

> On 30 April 2013 22:15, Thomas Neidhart <th...@gmail.com> wrote:
>
> > On 04/30/2013 11:09 PM, sebb wrote:
> > > On 30 April 2013 21:54, Thomas Neidhart <th...@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
> >
> >
>