Problem of defender methods with generic methods
Peter Levart
peter.levart at marand.si
Tue Nov 16 00:43:23 PST 2010
On 11/16/10, Alex Buckley wrote:
> On 11/15/2010 4:52 PM, Steven Simpson wrote:
> > Could it be done like this?:
> >
> > interface List<T> {
> > ...
> > <new T extends Comparable<? super T>> extension T max() default Collections.max;
> > }
I would expect that 'new' is actualy implicit in generic method declarations. Every type variable currently declared in a generic method is it's own instance (i.e. new).
What we might need is a syntax that says "this":
interface List<T> {
...
<this T extends Comparable<? super T>> extension T max() default Collections.max;
}
// which would mean that for a particular method, the type variable of the type instance should be bound accordingly or compile-time error is raised at a call site.
> >
> > The generic method signature as it appears in the bytecode would be
> > almost the same, but with some extra flag on T, e.g. '!':
> >
> > <!T::Ljava/lang/Comparable<-TT;>;>()TT
>
> It could, but don't forget to document the impact of additional bounds
> on subtyping (notably, containment of type arguments) and inference. The
> real question is whether library evolution commonly needs to so restrict
> type variables in the first place.
>
> Alex
>
> P.S. A better use of the "new" token in the context of a bound is to
> mandate that witnesses of a type variable have a no-args constructor, so
> you can say "new T()" in the body. But that's another story.
>
>
More information about the lambda-dev
mailing list