Notes on implementing concise calls to constructors with type parameters

[Howard Lovatt]

Neal,

The algorithm I am suggesting, textual substitution of missing items,
deals with the use cases yourself and Maurizio are discussing. Quick
recap; local variable declaration:

typeLHS [<genericParametersLHS>] name = new [typeRHS]
[<genericParametersRHS>] ( ... );

The proposed algorithm is that if typeRHS is missing then typeLHS is
substituted and if genericParametersRHS is missing and
genericParametersLHS is present then genericParametersLHS is
substituted.

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.

 -- Howard.

2009/5/15 Neal Gafter <neal at gafter.com>:
> On Thu, May 14, 2009 at 5:43 AM, Howard Lovatt <howard.lovatt at iee.org>
> wrote:
>>
>> Hopefully this is sufficiently detailed to enable you to comment.
>
> This proposal is completely non-orthogonal and ignores the relationship
> between the type parameters of the types on the right-hand-side (typically a
> class) and the left-hand side (typically an interface).  Assuming there is a
> one-to-one relationship is bad design, even though it is most frequently the
> case; the compiler knows the relationships between the types and should use
> it.  The proposal change the meaning of existing code (with respect to raw
> types).  It isn't clear how to make this proposal orthogonal to be used
> elsewhere than a variable declaration.  I suspect specifying this approach
> would result in a more complex specification than either the approach I've
> been advocating or the approach Maurizio has been implementing.
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
  -- Howard.