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

JEP 286: Local-Variable Type Inference

openjdk.java.net

Post reply on HN
Print view View original

101–110 of 132 posts

Re: JEP 286: Local-Variable Type Inference

#101

Post by echelon »

namelezz wrote: post #33
msbarnett wrote: post #13

Earlier quoted context omitted.

> I doubt if it's a good idea in practice since you can end up with unreadable code when integrating with third party APIs. This works perfectly fine in practice as can be seen using comparable constructs in C#, C++, and many other mainstream languages. If anything it's more readable, since your code isn't littered with redundant type info.

> If anything it's more readable, since your code isn't littered with redundant type info. I fail to see the redundant type info. Example 1: int maxWeight = blocks.stream() .filter(b -> b.getColor() == BLUE) .mapToInt(Block::getWeight) .max(); "int" is not redundant type info here. Example 2: List list = new ArrayList (); // (1) var list = new ArrayList (); // (2) Many would say List in (1) is redundant but I would a…

Have you never Map>? And then mapped it through various asynchronous transformations? Good god, the type soup.

There is a point where typing becomes verbose and decreases readability. If the compiler can infer, it should. It'll save time, money, and sanity.

Re: JEP 286: Local-Variable Type Inference

#102

Post by ubertaco »

nikolay wrote: post #46
dloose wrote: post #29

Earlier quoted context omitted.

Ceylon ( http://ceylon-lang.org ) has it too! Sorry. I just like Ceylon

With all the fuzz behind Kotlin, just because JetBrains, I am surprised that Ceylon has so little awareness! Ceylon, which has great features, multiple compilation targets (can't wait for the LLVM backend), has a great entity backing it (Red Had), and is created by a celebrity (at least in the Java world) developer (Gavin King)!

Yeah, and it seems like a good project, but some downsides are that it has to support multiple compilation targets (which can split a language into multiple ecosystems), has only one major user (Red Hat), and was created by Gavin King

Re: JEP 286: Local-Variable Type Inference

#103

Post by ubertaco »

gabriele wrote: post #99
ygra wrote: post #39

Earlier quoted context omitted.

How would type inference for local variables mess with fields?

according to Spring's documentation[1]: @Autowired is fundamentally about type-driven injection If you replace: @Autowired FooDao fooDao; with something like: @Autowired var fooDao; I'm pretty sure type-driven injection breaks. [1] https://docs.spring.io/spring/docs/current/spring-framework-...

Yeah, but that's a case where "var" is probably the wrong choice anyways, because of the non-obvious "human type resolution" -- i.e. if I'm a human reading this code, I can't obviously tell the type FooDao, where in simple cases like var path = Paths.get("/foo/bar/bonk") I can.

Re: JEP 286: Local-Variable Type Inference

#104

Post by radq »

gabriele wrote: post #99
ygra wrote: post #39

Earlier quoted context omitted.

How would type inference for local variables mess with fields?

according to Spring's documentation[1]: @Autowired is fundamentally about type-driven injection If you replace: @Autowired FooDao fooDao; with something like: @Autowired var fooDao; I'm pretty sure type-driven injection breaks. [1] https://docs.spring.io/spring/docs/current/spring-framework-...

The proposal only applies to local variables with non-null initializers. I'm pretty sure you can't autowire local variables with Spring, and they don't have initializers anyway.

Re: JEP 286: Local-Variable Type Inference

#105

Post by nikolay »

ubertaco wrote: post #102
nikolay wrote: post #46

Earlier quoted context omitted.

With all the fuzz behind Kotlin, just because JetBrains, I am surprised that Ceylon has so little awareness! Ceylon, which has great features, multiple compilation targets (can't wait for the LLVM backend), has a great entity backing it (Red Had), and is created by a celebrity (at least in the Java world) developer (Gavin King)!

Yeah, and it seems like a good project, but some downsides are that it has to support multiple compilation targets (which can split a language into multiple ecosystems), has only one major user (Red Hat), and was created by Gavin King

Red Hat > JetBrains though - I doubt Kotlin has a much bigger user base. Plus, being created by Gavin King is good, not bad. Also, multiple compilation targets are considered a plus in other languages (like Dart) - why is this bad for Ceylon? Especially when it along with Java it does not rely on native libraries like most of the other languages like Python, Ruby, and Node.js - it can be very useful and you don't need projects such as GWT if you can compile Ceylon to JavaScript directly.

Re: JEP 286: Local-Variable Type Inference

#106

Post by ubertaco »

nikolay wrote: post #105
ubertaco wrote: post #102

Earlier quoted context omitted.

Yeah, and it seems like a good project, but some downsides are that it has to support multiple compilation targets (which can split a language into multiple ecosystems), has only one major user (Red Hat), and was created by Gavin King

Red Hat > JetBrains though - I doubt Kotlin has a much bigger user base. Plus, being created by Gavin King is good, not bad. Also, multiple compilation targets are considered a plus in other languages (like Dart) - why is this bad for Ceylon? Especially when it along with Java it does not rely on native libraries like most of the other languages like Python, Ruby, and Node.js - it can be very useful and you don't nee…

Kotlin's got more "noise" around it lately though, so I suspect adoption will be quicker. Also, GMC is bigger than Red Hat, and while Telegram is smaller for sure, it's got a decent amount of weight to it. Both use Kotlin (at least according to the Kotlin homepage).

Gavin King is famous for three things in the Java world: creating the leaky-abstraction-riddled ORM Hibernate that never quite behaves the way you want, creating the never-really-used DI lib Seam that is notorious for being difficult to test and configure (despite standardized "javax" APIs), and being a difficult personality to work with.

Multiple compilation targets are a downside when: - It means that as a user of the language I have to write different code because the collections/scoping on one target behave much differently than on another - It means that as a maintainer of the language, I have to try to make core language features work with multiple very-different compilation targets, making the codebase N times harder to maintain, and usually meaning either that the language stagnates for long periods or that one platform is treated as "primary" and the others are second-class citizens that trail behind (see Scala on the JVM vs Scala.js, Clojure vs Clojurescript, F# vs Websharper, etc).

Re: JEP 286: Local-Variable Type Inference

#107

Post by wtetzner »

nikolay wrote: post #96
oldmanjay wrote: post #70

Earlier quoted context omitted.

What are the bad practices being promoted by this? How does it qualify as dumbed down? Simply ranting about things that, charitably, you don't seem to understand, does not make the rants valid.

The best practice is that the type of the variable is of the interface, not the implementation except in some special cases.

So stop using constructors and start using static factory methods. The return type of a static factory method can be the interface type.

Re: JEP 286: Local-Variable Type Inference

#108

Post by wtetzner »

mmatants wrote: post #19

I for one actually prefer to put a different type on the variable than the implementation. I.e. in the given case, I would actually use: `List a = new ArrayList ();` I know that for some things it is convenient, but I appreciate the reminder to treat interface and implementation as distinct concepts.

This is for local variables, though. You can use var as the return type of a method.

If your method bodies are so large that you need to be coding to interfaces within them (as opposed to just setting the return type of your method to the interface), the you've got other problems.

Re: JEP 286: Local-Variable Type Inference

#109

Post by TheCoelacanth »

gabriele wrote: post #99
ygra wrote: post #39

Earlier quoted context omitted.

How would type inference for local variables mess with fields?

according to Spring's documentation[1]: @Autowired is fundamentally about type-driven injection If you replace: @Autowired FooDao fooDao; with something like: @Autowired var fooDao; I'm pretty sure type-driven injection breaks. [1] https://docs.spring.io/spring/docs/current/spring-framework-...

var isn't a dynamic type. var is a compiler-inferred static type. `var fooDao;` will refuse to compile because the compiler can't infer the type. `var fooDao = new FooDao()` will still have the type FooDao for fooDao, it is just inferred by the compiler instead of being explicitly declared by the programmer.

Re: JEP 286: Local-Variable Type Inference

#110

Post by scalesolved »

skippytheroo wrote: post #89
scalesolved wrote: post #3

I hope this gets added to the language, we use Lombok heavily where I work and find it pretty great with it's val class that allows type inference, although it requires an explicit import and can't be used within Lambdas. The website isn't the prettiest but Lombok is a fantastic addition to a Java codebase and massively reduces the amount of boiler plate often associated with Java. A list of Lombok features https://p…

Lombok has always been a hacky set of language extentions. It says a lot about the need for more language features in Java that developers have been willing to resort to using it. Adding val and var to Java will be a big step forward.

Sure, no language is perfect but I've never ran into problems using Lombok in production. I'd gladly welcome the majority of its features being part of the core language though! :)
Post reply on HN