Notes on implementing concise calls to constructors with type parameters

[Howard Lovatt]

Neal,
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>();
    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
Ex<String>();

Hopefully this is sufficiently detailed to enable you to comment.

 -- Howard.

2009/5/14 Neal Gafter <neal at gafter.com>:
> Like Reiner, I suppose you have in mind a specification that would result
in
> the behavior you want without any undesireable side-effects.  I look
forward
> 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 iee.org>
> 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 http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
 -- Howard.