As one of multiple independent inventors of the diamond operator, I can give some insight.
Fundamentally, changes in Java are about working out what is deemed to be an acceptable change for Java developers, and what is acceptably in the "Java style". Both of these are subjective. In the initial discussion I had with a key person, the argument was that in Java the LHS of the declaration matters. Specifically that these two lines are not the same: List<String> list = new ArrayList<>(); var list = new ArrayList<String>(); because the latter declares a variable of the concrete type rather than the interface. The discussion ranged from the practical implications of that (relatively little) to the conceptual implications (Java devs like interfaces, and would see this as negative). In addition, the lack of a LHS type was discussed as not being "Java style". ALL of these things are to a subjective, and everyone reading this will ave their own opinion. (eg. I personally would be happy with var). Its just that the conclusion of the debate that day was an opinion that "Java style" would probably require LHS types, and thus the diamond operator. So, yes. The whole decision on diamond vs var was subjective judgements. But a number of key people came independently to the same conclusion. So, let no-one say it wasn't thought about. Stephen On Sep 22, 3:52 pm, Reinier Zwitserloot <[email protected]> wrote: > Because they aren't the same. > > Here you go: > > legal: > > List<Employee> emps = new ArrayList<>(); > emps = new LinkedList<>(); > > will fail, because LInkedList is not an ArrayList: > > var emps = new ArrayList<Employee>(); > emps = new LinkedList<Employee>(); > > This, and the problem of introducing a new keyword, were major reasons > for NOT going the var route. Furthermore, what diamond does already > exists in java so its only a very minor update: unlike constructors, > static methods _do_ infer, it's like they have implicit diamond > operators: > > this is legal today if you use guava: > > List<Employee> emps = Lists.newArrayList(); > > Now you know the thinking of the powers that be on the coin mailing > list. There's a nuance I've been arguing for on coin-dev back during > the time proposals were considered, which was two-fold: > > 1. There's no need for even diamond; just get rid of the idea of raw > for -source 1.7, and let that become 'infer it please'. It might even > be possible to remain backwards compatible. > > 2. While 'var' has all sorts of issues, both practical (new keyword is > a problem, and not being able to assign a LinkedList to an ArrayList > var is confusing), and ideological ("List" and "ArrayList" in List x = > new ArrayList() convey different meanings; they should not be mixed > up), these issues go away when we look at only FINAL variables. > There's no problem with confusion about assigning a LinkedList to > something initialized as an ArrayList. The ideological argument loses > a lot of its momentum when you realize that any kind of chaining on > expressions does not even allow you to list a more general type. > "final" itself can serve as the keyword, solving the last problem. > Thus, while this: > > var list = new ArrayList<String>(); > > wouldn't be legal, this should have been: > > final list = new ArrayList<String>(); > > unfortunately this idea was not accepted. > > On Sep 22, 5:21 pm, Serge Boulay <[email protected]> wrote: > > > Is there some particular reason Oracle choose the diamond operator over > > something like “var” ? > > > For example, I find this > > > List<Employee> emps = new ArrayList<>(); > > > far less intuitive than say > > > var emps = new ArrayList<Employee>(); > > > The second example has the added benefit that it would work with all types. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
