Notes on implementing concise calls to constructors with type parameters

[Howard Lovatt]

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.