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

61–70 of 131 posts

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

#61

Post by discreteevent »

trixie_ wrote: post #19
matt2000 wrote: post #3

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

Address address = contract.getAddress(); Not sure how this helps. I pretty much knew 'getAddress' would return some sort of Address structure. It's not like knowing the type name tells you what properties are on it. So what's the point?

With an IDE (or even most code editors) you can ctrl+click on Address to go straight to its definition.

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

#62

Post by moomin »

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…

C# developer here: my own take is that there are times when vat makes code harder to read, but your team should value identifying and avoiding that. In any event, it’s still perfectly possible to elude type information using techniques such as never declaring a variable in the first place. From this perspective it’s just one more tool in the armoury for writing readable code.

In its favour: It’s surprising how much code doesn’t really need the types written out to be readable (a discovery that will shock Python developers not at all). Furthermore, refactoring said code has less busywork in it.

As a side note: There’s one weird benefit of var not mentioned in this. Namely, you’re guaranteed there’s not going to be a cast. This is a serious problem in C++ where assigning the result of a function to a variable can have arbitrary side effects. (It’s not that bad in Java since pretty much all you can do is cast to interface.)

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

#63

Post by jrochkind1 »

zamalek wrote: post #25
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…

> You or some other maintainer will need to know what that type is later when reading the code. The Microsoft rule is to only use var when the type is obvious from the assignment. That essentially boils down to new, cast and anonymous types.

That seems to go against the OP's example benefits of very complex types or actually impossible types. The former will not be obvious from the assignment by nature of their complexity, no? The latter... well, being impossible without `var` implicit types is probably often also not obvious.

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

#64

Post by seanmcdirmid »

Thiez wrote: post #47
seanmcdirmid wrote: post #27

Earlier quoted context omitted.

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.

The big part of local type inference, which even Java couldn’t ignore, is the inference of method and function type parameter bindings for each call site. There should be some cost there, but it’s probably not much unless you are implementing something like Scala.

But, ya, var-style inferences are trivial.

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

#65

Post by ajkjk »

MichaelGG wrote: post #56
ajkjk wrote: post #37

Earlier quoted context omitted.

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 makes sense in "let x in {}" type expressions Without jumps, all code can be rewritten to be a series of "let x = ... in " The fact Java has statements instead of everything being expressions is a design flaw and should be rectified not glorified.

Er. Why do you think that?

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

#66

Post by TheDong »

discreteevent wrote: post #61
trixie_ wrote: post #19

Earlier quoted context omitted.

Address address = contract.getAddress(); Not sure how this helps. I pretty much knew 'getAddress' would return some sort of Address structure. It's not like knowing the type name tells you what properties are on it. So what's the point?

With an IDE (or even most code editors) you can ctrl+click on Address to go straight to its definition.

`var address` you can also in a short matter of clicks get to the definition of address's type, whatever it is, if you have an IDE.

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

#68

Post by cm2187 »

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…

On your point about the IDE helping you, there are two use case.

object i = new object();

I agree you only type once, the IDE will suggest object after new. But in that case the type is needlessly redundant, var could be use without making the code any less readable.

object i = myfunction();

Here the object is sementically useful but given that you have to type it before you type the name of the function I don't see how the IDE can possibly help you. Not only that but unless you know the return type of that function by heart it forces you to go check it out before you even start the line. And if you are using generics (or valuetuples) that could be a long type name.

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

#69

Post by rmrfrmrf »

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…

> any competent IDE can do it for you.

My biggest gripe with Java by far is the implied IDE requirement.

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

#70

Post by cm2187 »

zamalek wrote: post #25
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…

> You or some other maintainer will need to know what that type is later when reading the code. The Microsoft rule is to only use var when the type is obvious from the assignment. That essentially boils down to new, cast and anonymous types.

Unless you are writing C# in notepad, just hover the mouse over the variable and you get the type. Even when there is an ambiguity, it's really a minor inconvenience to whoever is reading the code.
Post reply on HN