Right, but what about:
final x = "Hello, World!"?
There's no type there, but the type of "Hello, World!" isn't visible
in this, either, and this is legal today:
int length = "Hello, World!".length()
On Sep 23, 2:15 am, JodaStephen <scolebou...@joda.org> wrote:
> 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 <reini...@gmail.com> 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 <serge.bou...@gmail.com> 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 javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
