Live data from Hacker News

Representing the Impractical and Impossible with JDK 10 “var”

benjiweber.co.uk

41–50 of 131 posts

Re: Representing the Impractical and Impossible with JDK 10 “var”

#41
post #37

"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.

It's math-y. As in "let n be a natural, ...".

Re: Representing the Impractical and Impossible with JDK 10 “var”

#42

Earlier 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.

Yes, this would be a nice addition, but I think final var might be able to stand in for it as of right now. One issue if it was adopted might be that “final” in Java doesn’t actually mean a whole lot, since there aren’t a lot of value types where mutation can be detected.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#43
post #38

Earlier quoted context omitted.

How so?

I guess the parent meant val as synonymous to final var, i.e. immutable.

var, let, val, there are so many of these and they all mean different things in different languages! It makes it hard to talk about them.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#44

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.

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”

#45
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

My experience with C++ is that auto sucks when you're reading someone else's code, and while it's a useful tool it's one that should be used thoughtfully.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#46

Earlier 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.

Or as in Kotlin.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#47
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…

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.

If the suggested `var` is anything like that of c#, there is no performance hit. When you type `Type t = some.expression()`, the compiler has to perform type inference on `some.expression()` anyway, otherwise it wouldn't be able to tell you when you've declared the type of `t` incorrectly. Indeed, when you write the wrong type there, the error message will actually tell you what type was inferred.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#48

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.

Also you can use "introduce variable" refactoring (ctrl+alt+V in Windows). Type "new Person("John")" and immediately press ctrl+alt+v.

Indeed, but for me that feels less natural. Matter of taste I suppose :-)

Re: Representing the Impractical and Impossible with JDK 10 “var”

#49
post #3
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…

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.

It is not at all clear that code readability is reduced by var-like type hiding.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#50
post #16
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…

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 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.

Post reply on HN