diamond operator & implementation strategies (v3)

[Maurizio Cimadamore]

Neal Gafter wrote:
> On Mon, Aug 24, 2009 at 6:04 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
>
>   
>> no arg constructor in method call => problem.
>> Correct me if I'm wrong but currently inference of method type
>> parameters also fails.
>> So It's not a big deal.
>>     
>
>   
@Remi: it's true, the complex approach has a similar behavior to javac's 
type inference. But to be honest I don't entirely understand your 
argument - since javac's type-inference is limited (some paper even say 
broken[1] ;-) ) you'd prefer a diamond inference scheme which is equally 
''broken''.

Apart from jokes, I think we are talking at different levels here: you 
are all very expert JDK/javac developers - you know every possible 
inference corner case, so that any failure looks familiar to you, 
because you know the rules of the game.

Choosing the simple approach is not about choosing the easiest path (see 
below) - it's first and foremost about optimizing the most frequent use 
case which is:

GenericVarType Ident = new GenericVarType(...);

This is what a client of the diamond feature expects diamond to be good 
at; and currently the complex approach is not able to deliver in this 
particular use case - as we said javac's type inference is to blame for 
that - but nevertheless I think it's important that we deliver something 
that people can intuitively use.

How do you think people is going to explain why this can be refactored:

Foo<Integer> fi = new Foo<>(1);

while the following cannot:

Foo<Number> fn = new Foo<>(1);

A developer who is familiar with inference problem will immediately spot 
the problem and think (as Remi did): well - it's type-inference that 
falls short here. But I don't expect this level of expertize to be the 
norm. Some people will think that the feature is broken and they will 
come back at us claiming that we should fix this.

@Neal: about simplicity; I totally disagree with the implicit statement 
that (i) the simple approach is the easiest path (see above) and (ii) 
that simplicity corresponds to the amount of lines of code in a patch. I 
haven't compared the two patches (they are linked at the bottom of my 
original mail[2] if you are interested in doing so) - on my part I can 
just say that they look pretty similar to me in terms of LOC - with one 
fundamental difference: the simple approach doesn't mess around with 
scope and resolution (and doesn't have to). I dubbed the 'simple' 
approach this way because of the impact it has on the existing language. 
In an earlier mail[3] I provided details about why I think the complex 
approach is 'complex'. And btw, it took me a couple of days in order to 
implement each - so it's not about time either :-) 

[1] http://www.cs.rice.edu/%7Edlsmith/java-type-system-oopsla08.pdf
[2] http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html
[3] http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html

Maurizio
> Agreed.
>
> What Maurizio calls the "complex" diamond inference approach is actually the
> existing generic method inference algorithm, but applied to constructors.  I
> prefer to call it the "compatible" algorithm.  The current method type
> inference has a straightforward extension to handle argument contexts that I
> expect is likely to be considered for a future extension.  It was actually
> in some late JSR14 prototypes, but removed in the latest versions due to
> concerns about the alignment of the spec and the implementation.  The
> compatible algorithm would naturally get the benefits of any improvement to
> method inference, including for argument contexts.  The "simple" version, on
> the other hand, does not have a straightforward extension to inference in
> argument contexts.
>
> In short, it mainly a big deal if the future evolution of the language is
> considered.
>
> The main reason that I've heard for preferring the "simple" algorithm is
> that it is simpler.  How many lines of code were required for each
> approach?  Now that both algorithms have been implemented that should hardly
> be much of a consideration, but it would be nice to know.
>
> -Neal
>
>