diamond operator & implementation strategies (v3)

[Rémi Forax]

Le 25/08/2009 10:52, Maurizio Cimadamore a écrit :
> 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''.

Yes, I prefer only one algorithm broken instead of two.
It's simpler for the future, after jdk7, we will have to fix only one 
algorithm, not two.

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

I don't think I know every corner cases :)
I use the 'teaching' metric.
If you introduce a new algorithm for diamond, I will have to teach it, 
and explain why it's different from the one used
for method inference so it will complexify something that is already not 
that simple.


>
> 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);

I already explain it because it's how the current method inference works.
I have to explain why

Foo<Integer> fn = Foo.create(1);

works but not

Foo<Number> fn = Foo.create(1);


So in my opinion, it's more simple to say
1) diamond works like method inference
2) the inference algorithm is sometimes broken but we will improve it.

To summarize, I don't see why you want that constructor inference work 
differently from method inference.

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

People already think that method inference is broken, and there are right.
We know we will have to provide a fix for method inference.
So when this fix will be available, it will fix the diamond syntax too.

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

Rémi