"var" did not grow on me. yet.

var did not grow on me. At least not yet.

A main rationale or at least one of the rationales of it were - to increase readability.
For me it actually decreases readability, and that's the main reason it didn't grow on me. When I see it, I have less confidence I understand it.


1.
Oracle provides some examples which sort of should hook you up on this:
var url = new URL("http://www.oracle.com/"); var conn = url.openConnection(); var reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));As opposed to:
URL url = new URL("http://www.oracle.com/"); URLConnection conn = url.openConnection(); Reader reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));But now imagine you need to use some other code that expects those types as arguments, I personally feel I'd need to check what's actually inferred by var and whether that would be what I actually need. Ok, later you may remove explicit type once you got details in agreement in order to shorten the line, but that's not more readable by any sense to me.


2.
Now, here is another example which experimented with:
var numbers = new ArrayList<Integer>();It is kind of de facto standard, what you really want here is:
List<Integer> numbers = new ArrayList<>();
Now if I define the following methods - both compile and work, that's a bit puzzling, looks like some sort of dynamic inference:
var numbers = new ArrayList<Integer>(); acceptList(numbers); acceptArrayList(numbers); // ... public void acceptList(List<Integer> numbers) {    System.out.println(numbers); } public void acceptArrayList(ArrayList<Integer> numbers) {    System.out.println(numbers); } I did not expect it to compile actually. Before I found out actually both compile, I didn't now for sure which one would compile either.
Not sure need to write it down down to lower readability or simply my lack of understanding.


3.
Another just came to mind to try (compiles):
var number  = true ? 1 : "2";

4.
Kotlin and Scala also have auto-inference, so it is not Java var that bugs me, I don't feel the need for auto-inference, I like types to be spelt out so no ambiguities left and I just find it harder to parse it in my head otherwise.

Slightly on a more worse side, you can't use var consistently throughout the code. It can't be an instance variable, it can't be parameter (understandable), just local variables - so for me that makes code look inconsistent.


I'm not against this change, just trying to find the way to get used to it.
Do you have some other perspective to provide which I could look at, why this feature could be liked by the wider community?

Liutauras Vilda wrote:. . .var numbers = new ArrayList<Integer>(); . . .

You wouldn't want var for something likeAnimal a = new Cat("Whiskers");It is only appropriate when the declared type and the runtime type wanted are exactly the same.

Another just came to mind to try (compiles):
var number  = true ? 1 : "2"; . . .

The compiler might be eliding that statement because of if (true).... It might be optimised away.

I agree. I haven't warmed up to it yet either. I feel it reduces readability especially when combined with streams. It adds that extra tenth of a second to full understanding of what I'm reading. I also feel that using explicit types helps flag issues during maintenance and refactoring phases. Not to say I've never used "var" but mostly not in production code.

This is a case where I don't practice what I preach.

I tend to advise people to only use var when the variable's type is clear from the expression that it was initialized with.

In my own code, I use it ALWAYS and EVERYWHERE. I like how much more concise my code is, how much better declarations of my local variable line up and it turns out I'm also just plain lazy. Maybe I'm tooting my own horn, but I think my code is plenty readable even when I use var everywhere I can.

Earlier, I wrote: var numbers = new ArrayList<Integer>(); acceptList(numbers); acceptArrayList(numbers); // ... public void acceptList(List<Integer> numbers) {    System.out.println(numbers); } public void acceptArrayList(ArrayList<Integer> numbers) {    System.out.println(numbers); }I did not expect it to compile actually. Before I found out actually both compile, I didn't now for sure which one would compile either.

I was wrong there, got confused. It is as simple as: ArrayList<Integer> numbers... of course. But it twisted my mind when I wrote this.

Stephan van Hulst wrote:how much better declarations of my local variable

Mine line up
LocalDateTime now = LocalDateTime.now(); ZoneId zid = ZoneId.systemDefault(); ZonedDateTime zdt = ZonedDateTime.of( now, zid );

That works in most cases, but gets quite tortuous when you have generic types with a lengthy list of type arguments.

Totally agree. Not against change but there's a certain kind o f change I never like - information hiding change.

This is happening not only in the language but in the IDEs as well. There's a certain mindset or personality or aesthetic (or something)  that appears to experience the presentation of "too much" information as noise.  For me personally, I want the information turned up to 11. It doesn't  confuse me or bother me and I make ready use of it constantly.  

I really think this is down to personal preference and the diversity with which people experience the world at some basic level.

It drives me crazy to see my IDE disappearing all the buttons and widgets and panels which I use. They're going for a "clean" or "beautiful"  look to their IDE but as I complained to them, it should be that form follows function. People think something is beautiful just because it's useful. The learned eye perceives a kind of  beauty in it because that worker understands how  the tool provides utility and saves effort. Its utility isn't improved just because it's made to look  "beautiful" or "simpler" or "cleaner" or "less cluttered" to just the eye.  That's driving everything the wrong way. Who cares how people who do not understand the tool or the job to be done experience the tool?  

var is like that. Somehow, I am supposed to appreciate the fact I don't  have to go to the trouble of specifying the type and the line of code is free of that  "clutter".  I do not experience it like  that.  I experience pretty much what you described.

But the fact is, not everyone is me. It's interesting to reflect that programmers as a class of people tend to be higher on the spectrum than most people and people on the spectrum are distinguished by having a low tolerance for "noise" or "clutter". I think this is at least part of the drive with languages like Kotlin which go out of their way to hide "unnecessary" information as much as possible. Nothing against these people and how they want things to be, I am just not one of them.      

Same thing at work with inner classes. People complained about the "ceremony' and "noise" of inner classes and this was one of the supposed features of lambdas (there are other points to lambdas and I use and like lambdas). I always felt the opposite way about inner classes. They clarified things to me by making them totally explicit. If you don't  know what class a  lambda is hiding  then you're losing out on an "en passant"   opportunity to learn something  about that class, like, at least, it exists, right?

Maybe information hiding is great if you know what information is being hidden (and never forget), but what if it's not your code? Then you have to take extra measures  if you want to understand the types involved. Sure everything like that is recoverable in the IDE but previously,  it was right there. That was better.

I always turn off every "information hiding" feature in the IDE I can find.  

     

While writing code, I focus more on the declared type of a variable rather than the actual object it points to. Since it takes me more brain cycles to parse code containing var, I use it rarely.
I also find reading someone else's code containing var frustrating.

I would rather prefer a var like shortcut on the right side  because I get the type of the variable in my head first

What I really want is List<Number> ln = new ArrayList<Number>(); and var can't give me that.

But if I ever want I write ArrayList<Number> an = new ArrayList<Number>(); I would prefer writing:
ArrayList<Number> an = newthis;

Paul Anilprem wrote:But if I ever want I write ArrayList<Number> an = new ArrayList<Number>(); I would prefer writing:
ArrayList<Number> an = newthis;

Interesting suggestion except the preferred way to write it is with List<...>, as in:
List<Number> an = new ArrayList<>();

Carey wrote:
Interesting suggestion except the preferred way to write it is with List<...>, as in:
List<Number> an = new ArrayList<>();

Of course. The diamond operator is quite useful here.

Just realized that newthis could be construed as another variable. So,

ArrayList<Number> an = new;

Oh I would so love that  

[Fixed quote]

Carey Brown wrote:List<Number> an = // is not the same as ArrayList<Number> an =

I know it is not. That's why I wrote this:

What I really want is List<Number> ln = new ArrayList<Number>(); and var can't give me that.

and then:

But if I ever want to write ArrayList<Number> an = new ArrayList<Number>(); I would prefer writing:
ArrayList<Number> an = newthis;

Meaning, I don't usually want to write ArrayList<Number> an = new ArrayList<Number>(); (which is what var provides and which is why I rarely use var) but if I ever do want to write it, I would have preferred something like:
ArrayList<Number> an = new;
instead of
var an = new ArrayList<Number>();

Hope that is clear enough

(Fixed formatting)

When this thread began, I didn't have anything useful to say. But anyway for my own interest I tracked down a document which addresses all of the things people might say about "var" (I think the JEP linked to it). One of the things in that document was this thing.

Their response was approximately:

Yes, we told you to write List<X> abc = new ArrayList<>() because in the absurdly unlikely event you wanted to use a different type of list, you would only have to change ArrayList to ThatOtherList in your code once instead of twice. And the <> feature ensures you only have to write the X once. But when you write var abc = new ArrayList<X>() you already get that, if you want to change ArrayList or X to something else then you still only have to change it in your code once. And it really doesn't matter that the type of abc is ArrayList instead of List.

It depends on my mood whether I write:
List<Thing> things = new ArrayList<>(); or:
var things = new ArrayList<Thing>();
In the past, I would have insisted on the first form, because I want to program against an interface and I don't need the variable to be of type ArrayList.

These days, I've grown more lazy and I don't really care as much that my local variables are typed too specifically. They're local variables after all, and their type won't leak beyond my method definition.

I guess the most important factor is whether I write professional code or hobby code. In professional code, I will be more reluctant to use var all over the place.