Notes on implementing concise calls to constructors with type parameters

[Neal Gafter]

I don't understand how this is all supposed to work when typeRHS is absent
and is then inferred to be a generic type involving wildcards (e.g. List<?
extends Number>).  Are we supposed to just drop the wildcards?

It seems madness to ignore the types of the (constructor) parameters, the
type parameter bounds, the relationship between the type parameters in
typeLHS and typeRHS, etc, in doing type inference.  That's probably not
something that can be done "later" because of compatibility.

For an example, consider

class Permutation<T> implements Map<T,T> { ... }

Textual substitution cannot work with this class.

Regards,
Neal

On Mon, May 18, 2009 at 1:13 AM, Howard Lovatt <howard.lovatt at iee.org>wrote:

> Hi Neal,
>
> Yes I should have spelled this out, it is one of those things obvious
> to the author but not to the reader. I would propose that given more
> than one method of the same name, method in example below, with the
> general declaration for each following the syntax:
>
> ... method ( typeLHS [<genericParametersLHS>] name , ... ) { ... }
>
> and given the call:
>
> ... method ( new [typeRHS] [<genericParametersRHS>] ( ... ) , ... );
>
> Then a three step procedure would be used:
>
> 1. If typeRHS is absent assume for step 2 type Void, where Void is the
> bottom type (in Java 7 this may be called Null but I chose Void to be
> consistent with the InvokeDynamic proposal)
>
> 2. Resolve method as normal and hence find typeLHS and if specified
> genericParametersLHS also
>
> 3. Apply textual substitution algorithm, i.e. If typeRHS is absent
> substitute typeLHS and if genericParametersRHS is absent and
> genericParametersLHS is present then substitute genericParametersLHS
>
> For example, given two methods:
>
> void method( Object notUsed ) { out.println( "Object" );  }
> void method( String notUsed ) { out.println( "String" );  }
>
> The call:
>
> method( new() );
>
> would print String because it would be translated by the textual
> substitution algorithm into method( new String() ), i.e. the same
> behaviour as method( null ) because null has type Void (bottom).
>
> Does that add sufficient clarity? I would be really interested if you
> can see a problem with the technique?
>
> If not the method maybe a good solution as it has many desirable
> characteristics (as listed in previous posts in this thread). I also
> note that many people would like a var or auto style declaration and
> maybe this proposal of text substitution can satisfy more people than
> other proposals, since it retains LHS types but saves re-specification
> of type, generic type, and doesn't require a diamond operator on the
> RHS.
>
>  -- Howard.
>
> 2009/5/15 Neal Gafter <neal at gafter.com>:
> > On Fri, May 15, 2009 at 12:26 AM, Howard Lovatt <howard.lovatt at iee.org>
> > wrote:
> >>
> >> Consider a simple method declaration:
> >>
> >> returnType methodName ( typeLHS [<genericParametersLHS>] name , ... ) {
> >> ... }
> >>
> >> and a simple method call
> >>
> >> ... methodName ( new [typeRHS] [<genericParametersRHS>] ( ... ) , ... );
> >>
> >> Then the same substituting of missing items algorithm given above can
> >> be used. The two examples that yourself and Maurizio have discussed
> >> would work, i.e.:
> >>
> >> *class X<T> {*
> >> *  public X( T t ) { ... }*
> >> *}*
> >>
> >> *void f( X<String> xs ) ...*
> >>
> >> the code
> >>
> >> *f( new X( "foo" ) )*
> >>
> >> gets translated into:
> >>
> >> *f( new X<String>( "foo" ) )*
> >>
> >> and:
> >>
> >> *void f( List<String> xs ) ...*
> >>
> >> the following method call
> >>
> >> *f( new ArrayList() )*
> >>
> >> gets translated into:
> >>
> >> *f( new ArrayList<String>() )*
> >>
> >> Therefore the textual substitution method proposed works for both of
> >> these cases.
> >
> > Is this textual substitution supposed to be applied before overload
> > resolution (i.e. before the method to be invoked is identified) or after
> > method resolution (i.e. after the types of the arguments have already
> been
> > resolved)?   Or are you planning a major overhaul of the specification of
> > method invocation expressions?  You haven't provided enough of a hint for
> us
> > to evaluate your proposal.  Can you please be more precise about what JLS
> > changes you are proposing?
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security System.
> > For more information please visit http://www.messagelabs.com/email
> > ______________________________________________________________________
> >
>
>
>
> --
>  -- Howard.
>