Notes on implementing concise calls to constructors with type parameters

[Neal Gafter]

One more thing.  What if "genericParametersRHS" contain captured wildcards
or conjunctive types?

On Mon, May 18, 2009 at 8:41 AM, Neal Gafter <neal at gafter.com> wrote:

> 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.
>>
>
>