Re: diamond operator
On 4/5/2012 2:34 PM, Lew wrote:
Arivald wrote:
It will be better to provide "auto" type detector, like in C++.
For example, instead of:
Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
use:
auto map = new HashMap<Integer, List<String>>();
...and "map" variable will be resolved at compile time to
HashMap<Integer, List<String>>.
This allow very handy construct, like:
auto data = SomeService.getProviders();
If 'auto' is a type, it should begin with an upper-case letter. If it's not, you should explain what you intend.
Given that it is a C++ keyword, then ....
In this case type of "data" will be deducted [sic] from return type of
SomeService.getProviders().
This will save lot of typing. And save refactoring time in case if
It will save virtually no typing compared to current Java idioms.
It will certainly save some typing.
But saving typing is not really important.
Your suggestion:
auto map = new HashMap<Integer, List<String>>();
Current idiom:
Map<Integer, List<String>> map = new HashMap<>();
Not much difference in typing, certainly not enough to get your knickers in a twist over.
Your suggestion:
auto data = SomeService.getProviders();
which you describe as "very handy", but violates strong typing, which requires that the compiler know the type of 'data'. If the (presumably static) method you describe were to change its return type, it would break the client code that relies on knowledge of the type of 'data'.
It is completely strong typed.
The compiler just infer the type instead of the programmer typing it.
It is available in lots of languages: C++, C#, Scala etc..
The current inference direction is that the generics of a method declaration are resolved by the invocation context, when possible:
Map<Integer, List<String>> data = getProviders();
where the declaration of the method is something like:
public Map<T, U> getProviders();
Type inference tells 'getProviders()' what types 'T' and 'U' are.
Your suggestion would break those.
No.
That could still work.
But you can obviously not infer on both L and R side.
You should understand that changes to the Java language must meet at least two criteria, irrespective of whether they even provide value (which I don't see that yours does):
- they must not break Java (which yours does), at least not too much,
It will not break Java.
C# got it in 3.0 and it did not break anything.
- they must provide enough value to justify making any change at all (which yours doesn't).
That is more an opinion than a fact.
Arne