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

121–130 of 131 posts

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

#121

Post by ionised »

kinghajj wrote: post #82
walshemj wrote: post #67

Can some explain the fist example says infers the type is right there in black and white var foo = new ArrayList (); It literally says exactly what foo is !!

Yes, but in current Java one would have to write ArrayList foo = new ArrayList () Or, at least List foo = new ArrayList () Whereas with `var`, as you show, the compiler infers the type. Proponents of this point out exactly what you did: the type is right there , so why should the programmer have to write it twice?

> List foo = new ArrayList()

List foo = new ArrayList()

> so why should the programmer have to write it twice?

You wouldn't.

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

#122

Post by vbezhenar »

akerro wrote: post #40
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.

Do you have any benchmarks for particular slow use-cases? I used to think the same, but in my quick benchmarks streams were as fast as handwritten code (may be a bit slower, but not much slower).

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

#123

Post by vbezhenar »

vbsteven wrote: post #115
vbezhenar wrote: post #111

Earlier quoted context omitted.

I don't like the fact that `var` breaks class hierarchy. I can write `List l = getList()` and then variable `l` will have only methods from `List`. If I'll decide to change `getList()` return type, it'll be easier to migrate the code. With `var` variable `l` probably will have something like `ArrayList` type and I can accidentally use methods from `ArrayList`, even if I don't really need them, tying this code to conc…

The problem here is not the `var` keyword but the `getList()` method that is leaking implementation details by having a concrete class return type instead of an interface.

But it's a good style: return concrete class, so if I really need those implementation details, I can have them without casts and potential runtime errors. Return as concrete type as possible and declare variable for holding this result as abstract as possible.

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

#124

Post by mrgriffin »

vbezhenar wrote: post #123
vbsteven wrote: post #115

Earlier quoted context omitted.

The problem here is not the `var` keyword but the `getList()` method that is leaking implementation details by having a concrete class return type instead of an interface.

But it's a good style: return concrete class, so if I really need those implementation details, I can have them without casts and potential runtime errors. Return as concrete type as possible and declare variable for holding this result as abstract as possible.

I disagree that this is a good style in general.

If I commit to returning an ArrayList then it's not backwards compatible if I want to change to a different concrete List. My experience has been that if you return a concrete class then people will rely on those details even when they don't need to. And if you're writing a library that others depend on then you don't even know how they're using your returned value.

Of course if people are doing unsafe downcasts because they need the guarantees of a particular implementation then you should just return the ArrayList directly. And fortunately this change is backwards compatible, so there's no need to worry!

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

#125

Post by kazinator »

ajkjk wrote: post #37
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.

> I don't see any argument for it in a C-like language.

The inventor of the C-like languages B and NB (which then inspired C) agreed and used the more intuitive auto.

  {
    auto x = 1; /* x is implicitly an integer */
  }
Now it's back in vogue in the C-like language C++. It doesn't mean "automatic storage", though.

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

#126

Post by taejo »

DonHopkins wrote: post #54
Thiez wrote: post #47

Earlier quoted context omitted.

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.

It reminds me of one of Bertrand Myer's many criticisms of C++ that I read in his book on Eiffel. (Almost every page of his book made fun of C++ in some way -- it was a delightful read!) He pointed out that there was no reason for C++ to have both "." and "->", because the compiler always knew which one was required, and it only gave the programmer the opportunity to make a mistake, and a lot of extra effort changing…

And now you can't do it in C++ any more because you can overload operator->

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

#127

Post by jayd16 »

ionised wrote: post #119
jayd16 wrote: post #20

Earlier quoted context omitted.

Var makes refactoring way easier while being just as safe and informative.

How?

You can change concrete types of methods without refactoring variable declarations. For example ,its nice when dealing with collections without referencing them as an interface. You might think "whats so wrong with using the interface as the declared type?" In C# you can run into issues with using interfaces as things like enumerators are objects in the interface but concrete types can use optimized structs.

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

#128

Post by stickfigure »

trixie_ wrote: post #92
stickfigure wrote: post #89

Earlier quoted context omitted.

This is a poor argument for var. Competent Java programmers use the extract-to-variable keybinding (Cmd-Opt-V in my environment); it even guesses the variable name correctly.

Having the type name doesn't tell you anything about the type itself. Unless you have the type definition memorized, having the type declaration there is not very useful. If I replaced the types above with var, you would still be in the dark as to what an Account and/or Transaction is without going to the type definition.

Eh? There's a lot of information here, even without familiarity with the code (and really, most people have at least a partial understanding of the codebases they work on).

I can see that the thing returned from getAccount() is an Account object! It's not an accountId, or the name of the account, or an AccountDTO, or an Optional, or any of the dozen other things I've seen people return from methods named getAccount().

Depending on how methods are named, the implicit documentation can be very helpful:

    Account from = transfer.getFrom();
I don't think that var is particularly evil, but I think it has a poor case for existence. Meh.

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

#129

Post by DonHopkins »

taejo wrote: post #126
DonHopkins wrote: post #54

Earlier quoted context omitted.

It reminds me of one of Bertrand Myer's many criticisms of C++ that I read in his book on Eiffel. (Almost every page of his book made fun of C++ in some way -- it was a delightful read!) He pointed out that there was no reason for C++ to have both "." and "->", because the compiler always knew which one was required, and it only gave the programmer the opportunity to make a mistake, and a lot of extra effort changing…

And now you can't do it in C++ any more because you can overload operator->

I vaguely remember that there was some annoying guy on comp.lang.c++ years ago who relentlessly campaigned for "operator .", because he was sure that it would somehow make C++ amazingly powerful and easy to use. But many people seemed to disagree with him and had problems with it, because it never happened.

Anybody remember what the controversial benefits and problems of "operator ." were? Here's something I just found about that:

https://isocpp.org/blog/2016/02/a-bit-of-background-for-the-...

But that's coming from the same madman who wrote the proposal for "Generalized Overloading for C++2000" that actually let you overload whitespace with "operator ' '".

http://www.stroustrup.com/whitespace98.pdf

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

#130

Post by taejo »

DonHopkins wrote: post #129
taejo wrote: post #126

Earlier quoted context omitted.

And now you can't do it in C++ any more because you can overload operator->

I vaguely remember that there was some annoying guy on comp.lang.c++ years ago who relentlessly campaigned for "operator .", because he was sure that it would somehow make C++ amazingly powerful and easy to use. But many people seemed to disagree with him and had problems with it, because it never happened. Anybody remember what the controversial benefits and problems of "operator ." were? Here's something I just fou…

Whitespace overloading was an April Fools' joke
Post reply on HN