Notes on implementing concise calls to constructors with type parameters

Howard Lovatt howard.lovatt at
Fri May 15 00:26:43 PDT 2009


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

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" ) )*


*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>:
> On Thu, May 14, 2009 at 5:43 AM, Howard Lovatt <howard.lovatt at>
> 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
> ______________________________________________________________________

  -- Howard.

More information about the coin-dev mailing list