diamond operator & implementation strategies (v3)
Maurizio Cimadamore
Maurizio.Cimadamore at Sun.COM
Tue Aug 25 01:52:09 PDT 2009
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
>
>
More information about the coin-dev
mailing list