Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Representing the Impractical and Impossible with JDK 10 “var”

benjiweber.co.uk

Post reply on HN
Print view View original

31–40 of 131 posts

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

#31

Post by dlp211 »

extrememacaroni wrote: post #10
arcticbull wrote: post #8

Earlier quoted context omitted.

I'd suggest that means your `getAddress()` name could be improved to convey the necessary information.

`getAddressWhichIsOfTypeString()`? `str_GetAddress()`? `GetAddress_STR()`?

Why would an address be a string? That's poor use of types. I would expect that getAddress() returns an Address. If it did return it as something non-obvious, than I would expect that to be expressed through the interface and thus the call would be getAddressAsString().

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

#34

Post by saagarjha »

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

Your comparison is surprisingly apt, since both languages commonly have long type names (std::vector::iterator, etc.) and I often find that code that does type inference often reduces clutter because I don’t have to know the exact type that something is, but by looking at the code I generally can know what the “high level” type is.

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

#35

Post by saagarjha »

The “impossible” part of the title is an interesting one, since it mirrors how the arrival of lambdas coincided with the arrival of auto in C++ because such types are similarly impossible to represent. As I’ve mentioned in another comment in this thread, I think Java and C++ are very similar with regards for the need of type inference because they end up having a lot of the same issues.

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

#36

Post by rbonvall »

saagarjha wrote: post #33
vbezhenar wrote: post #24

I'm very disappointed that they didn't make `val` keyword. Very simple change but code becomes significantly more readable and a lot of bugs will be compile errors.

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”

#37

Post by ajkjk »

lkjlakjsdlfkj wrote: post #14

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

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

#38

Post by krotton »

saagarjha wrote: post #33
vbezhenar wrote: post #24

I'm very disappointed that they didn't make `val` keyword. Very simple change but code becomes significantly more readable and a lot of bugs will be compile errors.

How so?

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

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

#39

Post by scarface74 »

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…

Why as a maintainer should var make the type harder to know? It's right there on the screen when you are initializing the variable and hopefully you're naming your variable something to make it obvious (not Hungarian notation).

If you your method is too large to fit on the screen, the method is probably too long.

But what competent IDE doesn't allow you to just hover over the variable to the know the type?

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

#40

Post by akerro »

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…

Well, I don't like streams in Java, they make code much slower, it looks fancies, but in real time, streams are often abused and make code run longer in almost every case I measured (I took some methods from Github, SO and reddit comments). Equivalent for loop/for-iterator loop is much faster. Solution: you don't have to use it, you can educate others how to use it properly.
Post reply on HN