You can always assume that it's the most restrictive type that you want. How many times did you really need Map<Object, Object>, when you initialised the map with {"abc":1, "def":2, "ghi":3} ?
Since you can always make it specific what you want, you can assume that the most common case is the "default". That's what c#'s `var` does anyways - if you have a `var a=1;`, 'a' an int, not an object. If you use `var a=new []{1,2,3};`, it's int[], not object[].
It's not. How many OOP languages do you know where type-inference works?
I know of none ... Ocaml uses a special syntax for reconciling the type-inference with the inclusion polymorphism that it supports ... (name : sub_type :> super_type). And IMHO it gets ugly.
I'm not really clear about what "type unification" you're referring to, but the actual types in Java aren't known until runtime (you usually only know a parent). To change this behavior an overhaul of the entire architecture is needed.
How many OOP languages do you know where type-inference works
C#
Not "type-inference" in the very general sense, just "type-inference" in the "when you see 'var someVar = 3;' you can infer that someVar is of integer type" sense. Which is what java is doing again. Playing catch-up to c#.
Java is not adding local type inference as in C#.
It only adds the diamond construct for inferring the generic types from the variable's type being assigned ...
Map<String, Integer> m = new HashMap<>();
Which is ugly, but many Java developers are taking "programming to an interface" rule quite literally.
Those only work for local declarations where the type of the expression is known.
This thread was talking about type inference in this case ...
var l = [12.4, 13, "a string"];
This would require the array to have generic arguments, and those generics arguments to be inferred from the types given to the constructor (in this case the base class would be Object). I think it works in Scala, but a type unification is really hard ... i.e. to be able to write your own generic functions / classes with the generic type inferred from the base class of the given arguments.
The definition of a generic function that would do this would look like ...
Array<T> createArray<T> (T ... args)
Also, since generic definitions are a PITA to write and read, many people dream of a Hindley-Milner type system where the generic type is discovered. But I don't know of a single OOP language that does that (Ocaml and F# try, but it's ugly) since OOP polymorphism is not compatible.
The difficulty is how you define "most restrictive" in a strongly typed language. If I have classes which implement multiple interfaces which aren't subsets of each other... maybe cloneable and serializable? Which is more restrictive? Does C# solve this?
As viraptor said, it's always safe to just use the most restrictive type. Type inference is quite useless if you just infer everything to be an Object :)
And beside, in cases of ambiguity, you can mandate the use of the verbose form.
I was thinking specifically of the example in C# where you can do something like:
var list = new[] { "hello", null, "world" }
which the runtime casts as a string[].
It just seemed like these collection literals would be good candidates to use the new type-inference capabilities they're rolling out.
Specifically because of Java's wildcarding, there is an important difference between a Map<Object, Object> and a Map<? extends Object, Object>; a Map<String, Object> is not the former and is an example of the latter. This comes up in method definitions quite frequently.
Yes, this is a really stupid feature of the language.
This one is of course a circular debate that will live forever, but you might expect to be able to insert an Integer key into a Map<Object,Object>, which you can't for a Map<String, Object>, so to say the second "is" an instance of the first doesn't really work.
You are, of course, quite right, which is why I said that a Map<String, Object> isn't a Map<Object, Object>. However in Java's typing scheme it is a Map<? extends Object, Object>, which represents a key that extends Object (very specific, that) and among other things won't let you insert anything into it.
It's kind of trivial in your example, but with complex objects that implement a lot of interfaces it isn't as obvious what the programmer means.