Representing the Impractical and Impossible with JDK 10 “var”

Post by Insanity » Sun, Mar 04, 2018, 11:40 PM UTC

adrianmonk wrote: post #60

Insanity wrote: post #29

It's one of the things I really missed when going from C# to Java, but with IntelliJ, the typing experience is very similar from C#. Imagine I want to have a variable like: Person p = new Person("John"); All I would type in IntelliJ is: new Person("John").var After pressing "tab", that will autocomplete for me and put the focus on the variable name so I can rename it from the default inferred value.

Don't most decent IDEs support something like that? In Eclipse you can just type new Person("John") And then hit Ctrl-2 L.

Post by Thiez » Mon, Mar 05, 2018, 12:03 AM UTC

spion wrote: post #72

pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

Its so funny, watching Java fans talking about silly things like `var` whilst their language gets more obsolete every day. I'm so sorry, but basic type inference won. Can you please go away so we can get a good ecosystem and a good language (with first class support VM wise) to go with it in a single package? On a side note, its getting very tiring to rewrite the whole ecosystem every time a language is being annoyin…

Post by gravypod » Mon, Mar 05, 2018, 12:06 AM UTC

pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

Post by reuben364 » Mon, Mar 05, 2018, 12:15 AM UTC

mpfundstein wrote: post #6

pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

People said the same thing about auto in C++. Few years later and everyone I know (and codes C++) loves it and uses it all the time. Its a great addition and like lambas will certainly improve how we write Java

Post by kochthesecond » Mon, Mar 05, 2018, 12:30 AM UTC

Amelorate wrote: post #50

trixie_ wrote: post #16

Earlier quoted context omitted.

I'm pro var * I write code a lot more fluidly with var. When I go back to writing non-var code (enforced by some departments) I find that it breaks my focus on solving the problem at hand. I end up writing my code with var and then going back and replacing my vars with the type names. * I find code a lot easier to read. I can understand the flow of the logic easier, the variable names are enough. Unless you have the…

Counter-argument to changing the return type of a function with var: You can change the return type of the function to another type that might break some assumptions later in the code. For example, if the code assumes it has a type Foo with a length field, and you change the return type of tha function to a Bar without that length field, the compiler will complain that Bar doesn't have a length field, rather than com…