Not that I don’t understand the idea. It’s simple:
final map := new HashMap<String,List<Thing>>();
is equal to
final HashMap<String,List<Thing>> map =
new HashMap<String,List<Thing>>();
And who really wants that kind of line in their code, eh? Why write things twice, anyway?
The proposal in Neal’s blog is considerably sane too, because it offers a way to allow a developer to choose not to use type inference. Some people even offered generic-type inference according to the types passed to the constructor:
final numbers := new ArrayList<>(1, 2)
is just the same as
final ArrayList<Integer> numbers = new ArrayList<Integer>(1, 2)
And again, who wants all this extra verbosity anyway? But let’s take a look at a few possible following lines of code:
// compiler error: sort accepts the List interface This is okay, my mistake.
Collections.sort(numbers);
// compiler error: this is a list of Integers, not Numbers.
list.add(new Double(2.0));
Now, I realise that some language changes also change the way we developers do things; the for loop change was a great change, and obviously there was probably someone going “oh, but you can’t access the iterator/array index and it’s really useful to be able to”. In the end, it’s not that needed; more than that, some people still complain that the for construct could be even better with an additional (optional) colon, followed by the name of a local variable to hold the usually implicit iterator/array index.
The question is, how many of these instances are actually there? And how many instances of these variable creations are eventually doomed to explicit definitions due to return values, method parameters, specific generic type requirements, or just because they don’t want to be declared final? This is an interesting question, and looking at Yielder as a test case, I wonder how much of it could be transformed to this new syntax, and how much is forced to stay explicit?
I will try (with the little free time I actually have) to chart this out, if it’s of any interest to any of you. I would also appreciate something similar done in return, done on your own projects, if possible!
Update: I made a mistake when writing this post, note above. I guess I was tired to think when I started writing it, and didn’t notice the mistake later on. I still stand behind what I say about inference of generic types, and I still think interfaces should be used instead of concrete classes, though.
September 27th, 2007 at 3:44 am
I don’t know if it should be (and I could be wrong in my thinking), but it should resolve to interfaces and abstract base classes instead like this:
final List<? extends Number> numbers = new ArrayList<? extends Number>(1, 2)Either way, I think the trick will be to ensure that the inferred type syntax does not break the ’statically typed’ nature of the Java programming language.
Edited by Avah to add generic formatting, hope this is what you meant…
September 27th, 2007 at 7:51 am
I agree it should be made of interfaces and abstract classes, but how will it know? It’s not that I’m afraid of a very smart compiler, but will it have to analyse the code in order to understand that I wanted it to be
List, and not, to take an example of another top interface ofArrayList,RandomAccess?The same goes for generic types, too - it’s just even more complex there, I think, because it might be
? extends Tor? super T, according to some crazy logic..October 3rd, 2007 at 5:55 am
[…] Chaotic Java had a post this week about type inference and whether it would be worth it. […]
October 3rd, 2007 at 8:16 pm
Well, the idea of type inference is not only about not writing things twice, it’s rather about not writing them at all :
final map := new;
And the compiler will infer whatever typing information is needed, looking at how you’re using your map. That doesn’t imply that you cannot write additional information typing information when you want to or when the compiler is not able the infer a type.
The point of type inference is that your program *is* statically typed. Every variable has one and only one type. It’s just that you don’t have to write it.
Java goes much in the way of type inference, though. This is the main reason why this looks so cryptic to Java developers. For instance, Java class files do not make possible to specify parametric types for fields, so whatever Java language extension you can think of, you will always need to deal with that limitation, resulting in strange restrictions at the language level.
October 3rd, 2007 at 10:45 pm
The idea behind local variable type inference is to declare type when
it’s usefull and not if it’s not usefull.
By the way,
new ArrayList()
is illegal, ArrayList is an abstract type,
like a kind of interface and not an actual class.
Rémi
October 3rd, 2007 at 10:59 pm
Ermm…
I hate to say this, but 1) I know what an abstract class is… (Seriously…?) and 2) ArrayList is not one of those.
So.. I suspect this isn’t you, Remi.
October 3rd, 2007 at 11:02 pm
Gen: What you’re suggesting seems irrational to a developer’s mind. I can see, from time to time, how IntelliJ manages to guess a type from it’s usages. But for a compiler to do so… That would be too much to as for, I suppose. Especially to guess a concrete type.
Do you know of a language that does something like that?
October 4th, 2007 at 12:34 am
Sorry, the < and > diseapear.
the correct message is:
By the way,
new ArrayList<? extends Number>()
is illegal, ArrayList<? extends Number> is an abstract type,
like a kind of interface and not an actual class.
October 4th, 2007 at 7:29 am
Oh, now I get it.
Yes, it doesn’t accept it. The compiler error is that it’s due to a boundless type in the type arguments.
Regarding what you said, I understand that you’re supposed to use it when it’s useful.. I was just wondering if anyone has done any checks to see how many times it is useful within a project’s code-base.
November 13th, 2007 at 12:41 am
I really think there is an unnatural reaction from Java developers with Explicit Type Parameters.
I wanted to answer but it was too long so here it is:
http://freddy33.blogspot.com/2007/11/ugly-duckling-of-java.html