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