Notes on implementing concise calls to constructors with type parameters

[Howard Lovatt]

Hi Neal,

Comments in text below.

On 15/05/2009, at 2:32 AM, Neal Gafter <neal at gafter.com> wrote:

> 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 advantage of the proposed algorithm is that it is for both the  
compiler and programmer. For example if someone writes:

List l = new();

Then this is equivalent too and will generate the same error message as:

List l = new List();

So I don't see a problem with this, it is identical to current Java.

If you want an symmetric declaration then you need to specify the  
asymmetry, e.g.:

List<String> ls = new ArrayList();

Becomes:

List<String> ls = new ArrayList<String>();

I will come back to this example below.

>   The proposal change the meaning of existing code (with respect to  
> raw types).

The change in the raw types is as given above for the ArrayList  
example. I don't think that this change will be a bad thing because at  
present:

List<String> ls = new ArrayList();

Is almost certainly a typo or a lazy bit of coding and therefore the  
change will fix these problems rather than break code.

Other uses of raw types, e.g.:

List l = new ArrayList();

Are unchanged.

> It isn't clear how to make this proposal orthogonal to be used  
> elsewhere than a variable declaration.

I don't see this. For example the type declaration of a method  
parameter can be considered like the LHS of a declaration. If generic  
parameters are infered then you might have to specify them as you do  
at present - i.e. no change.

> 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.

I think the great advantage of this approach is that it is easy to  
describe and easy to understand - because it is sytax sugar only.

>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________