Notes on implementing concise calls to constructors with type parameters

Howard Lovatt howard.lovatt at
Thu May 14 05:43:47 PDT 2009

The conceptual algorithm that I suggest is text substitution of the missing
items. It is a conceptual algorithm, I am not saying the compiler has to
literally do this, just that the compiler does this or the equivalent of
this. As an example consider an abstract form of the proposed declaration
for a simple, i.e. not a complete specification but an example, 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
genericParametersLHSis present then
genericParametersLHS is substituted.

The following concrete example illustrates what is proposed. The example
below names the variable using 4 letters, the first is e which stands for
type Ex, the second is optional and if present is s which stands for generic
parameter String, the next letter is e if the RHS specifies the type, and
the last letter is s if the RHS specifies String. The last three letters are
optional and if absent an _ is used. This naming convention allows naming of
the examples.

 private static class Ex<T> {
   Ex() {}

   // Translation                      // Original
    Ex         e___ = new Ex();         // Ex         e___ = new();
   Ex         e__s = new Ex<String>(); // Ex         e__s = new<String>();
    Ex         e_e_ = new Ex();         // Ex         e_e_ = new Ex();
   Ex         e_es = new Ex<String>(); // Ex         e_es = new
    Ex<String> es__ = new Ex<String>(); // Ex<String> es__ = new();
   Ex<String> es_s = new Ex<String>(); // Ex<String> es_s = new<String>();
    Ex<String> ese_ = new Ex<String>(); // Ex<String> ese_ = new Ex();
   Ex<String> eses = new Ex<String>(); // Ex<String> eses = new

Hopefully this is sufficiently detailed to enable you to comment.

 -- Howard.

2009/5/14 Neal Gafter <neal at>:
> Like Reiner, I suppose you have in mind a specification that would result
> the behavior you want without any undesireable side-effects.  I look
> to seeing that spec.  Until then, there isn't really much to comment on.
> Regards,
> Neal
> On Wed, May 13, 2009 at 8:41 PM, Howard Lovatt <howard.lovatt at>
> wrote:
>> The suggestion from Reinier that:
>> List<String> foo = new ArrayList();
>> infers ArrayList<String>, seems like a good idea to me (for one thing
>> it is consistent with how you use generic static methods and as Ulf
>> pointed out people already write this and suffer the warnings). Also
>> the present system, because or erasure, isn't type safe as it stands,
>> e.g.:
>>    final List<String> ls = new ArrayList<String>();
>>    final List lr = ( List ) ls;
>>    lr.add( 1 );
>>    System.out.println( " ls = " + ls );
>> and Reinier's change would if anything increase type safety.
>> Even if there are some minor incompatibilities, it would be worth it.
>> I am not a fan of the <> syntax, it looks ugly and if anything implies
>> raw type to me rather than inferred type. A further suggestion along
>> Reinier's lines, allow:
>> ArrayList<String> foo = new();
>> to be equivalent to:
>> ArrayList<String> foo = new ArrayList<String>();
>>  -- Howard.
> ______________________________________________________________________
> 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