Representing the Impractical and Impossible with JDK 10 “var”
benjiweber.co.uk
Representing the Impractical and Impossible with JDK 10 “var”
1–10 of 131 posts
Re: Representing the Impractical and Impossible with JDK 10 “var”
#2While 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't actually need to enter in the type, any competent IDE can do it for you.
So I'm not sure what we are saving here. When has the time spent typing in code ever been a bottleneck in software development anyways?
This is my feeling from having worked extensively in Java as well as languages that support "var": C# and Swift. I feel like my productivity goes down when I have to support code that uses inferred types. There also seems to be a performance hit when compiling code with inferred typing, although that may be circumventable with better compiler tech, who knows.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#3While 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…
I agree. It seems very clear that code readability is reduced by var-like type hiding. When I'm doing code review and I see "var address = contract.getAddress();" what is the type of that variable? I have no idea.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#4While 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…
I agree. It seems very clear that code readability is reduced by var-like type hiding. When I'm doing code review and I see "var address = contract.getAddress();" what is the type of that variable? I have no idea.
This, on the other hand, seems perfectly reasonable to me:
var c = new Customer();
Re: Representing the Impractical and Impossible with JDK 10 “var”
#5While 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…
What are your opinions about python, as it has no explicit type for readability.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#6While 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
Re: Representing the Impractical and Impossible with JDK 10 “var”
#7While 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…
I felt the same exact way about Rust. A few years later, it's totally liberating. I do get lost from time to time, but the savings relative to spelling that stuff out is enormous. IDE support where you mouse over and it tells you what the inferred type is even better, IMO, as you get the "right" answer with full precision not the "coerced" wherein you may have erased some type info.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#8While 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…
I agree. It seems very clear that code readability is reduced by var-like type hiding. When I'm doing code review and I see "var address = contract.getAddress();" what is the type of that variable? I have no idea.
I'd suggest that means your `getAddress()` name could be improved to convey the necessary information.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#9While 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…
> "var" is meaningless, requiring you to dig back one or more steps to determine the actual type.
> You don't actually need to enter in the type, any competent IDE can do it for you.
These two points contradict each other. Any competent IDE can visualize the inferred type even if you don't spell it, for example as a tooltip.
This is not (only) about typing, it's about the visual noise and redundancy caused by explicit types. Plus, as the article illustrates, the ability to give names to expressions that have very complex types, reducing the need for type erasure.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#10Earlier quoted context omitted.
I agree. It seems very clear that code readability is reduced by var-like type hiding. When I'm doing code review and I see "var address = contract.getAddress();" what is the type of that variable? I have no idea.
I'd suggest that means your `getAddress()` name could be improved to convey the necessary information.
`getAddressWhichIsOfTypeString()`?
`str_GetAddress()`?
`GetAddress_STR()`?