"let" is more elegant IMO.
I always found 'let' to be such a strange name. What on earth is appealing about it? The usual variable declaration syntax is ; it's not a stretch to imagine the type as 'var', a catchall type. But 'let'? Let is a verb; it should be in a place where functions, not types, go. It makes sense in "let x in {}" type expressions, and it kinda makes sense in Lisp, but I don't see any argument for it in a C-like language.
Representing the Impractical and Impossible with JDK 10 “var”
41–50 of 131 posts
Re: Representing the Impractical and Impossible with JDK 10 “var”
#42Earlier quoted context omitted.
How so?
I'm sure he means `val` as in Scala, where it is used to define a name that cannot be rebound: val x = 1 var y = 2 x = 3 // compile error y = 4 // ok It makes it easier to read code since you don't have to keep track of changes in your head.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#43Re: Representing the Impractical and Impossible with JDK 10 “var”
#44It'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.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#45While 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”
#46Earlier quoted context omitted.
How so?
I'm sure he means `val` as in Scala, where it is used to define a name that cannot be rebound: val x = 1 var y = 2 x = 3 // compile error y = 4 // ok It makes it easier to read code since you don't have to keep track of changes in your head.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#47While 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…
There is no appreciable performance hit for locally inferred types given that the compiler isn’t doing much. Globally inferred types can take a hit, though most of those are based on Hindley Milner which can be pretty efficient.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#48It'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.
Also you can use "introduce variable" refactoring (ctrl+alt+V in Windows). Type "new Person("John")" and immediately press ctrl+alt+v.
Re: Representing the Impractical and Impossible with JDK 10 “var”
#49While 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”
#50While 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'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…
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 complaining about trying to assign a Bar to a variable of type Foo.
Even worse is if the Bar type changes the symantics of that length field (perhaps going from the number of elements to the max index of elements, causing an off-by-one error), the code could break silently.
That's mostly a strawman argument, however it is worth noting.