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.
JEP 286: Local-Variable Type Inference
21–30 of 132 posts
Re: JEP 286: Local-Variable Type Inference
#22From Java LINQ Examples: https://github.com/mythz/java-linq-examples
Re: JEP 286: Local-Variable Type Inference
#23Collection getNames() { ... }
and in your code you do
var names = getNames(); if (...) names = Collections.emptySet();
Now, if the api later changes getNames() to be
List getNames() { ... }
your code breaks. That's one of the advantages of only allowing this on final variables (besides reusing an existing keyword): it means this can't happen. Of course you already have a problem if the class has subclasses but I would argue that this is more subtle and problematic.
Re: JEP 286: Local-Variable Type Inference
#24A while back, I was trying to explain in what ways Scala is more typesafe than Java for a friend (which was one argument to why I prefer Scala so much), and ended up realizing how important type inference is in this regard.
The reason was this: quite often type signatures correctly modelling a domain ends up being pretty hard to read. In a good and proper API, this happens in particular whenever something is composable and is, in fact, composed (if one can say that). I suppose one can say that, for Scala, it took a bit of time before people figured out how to do this properly, rather than just hacking the type system, but I feel that the ecosystem is more or less there now... YMMV though...
As an example: in something like Slick (a functional-relational mapper) in Scala you end up with monads to model your SQL query. One advantage this has is compile errors whenever you're doing something wrong (i.e. more typesafe), but the types that a SQL query representation ends up with will necessarily be pretty hard to read and practically impossible to write (you could have a Query of a long chain of other types for example if you're querying multiple columns). In this example, somebody writing the query might not care about the type of the query. They will care about what the query will end up returning when executed though. I suppose it will lead to trouble when you can't read the type signatures well enough and try to figure out the compiler error, but I reckon it's better to have an error, than to see it fail runtime (at least in my world :). It's easier and safer to do maintenance too, since the compiler and IDEs can know how things should work.
In any case, you could conclude that, in a statically compiled language where you do not have type inference, you'll end up trading in preciseness in the model of the domain, in order to have readable code from the callsite. In turn, this leads to less typesafe code.
One challenge that Java will have even when implementing this though, is how to move the entire ecosystem to something that is indeed more typesafe. This only works if the APIs are doing this right.
EDIT: typos, language and less parens
Re: JEP 286: Local-Variable Type Inference
#25Hey look, it's something else that's been implemented in almost every other JVM language that hasn't made it into Java yet.
Re: JEP 286: Local-Variable Type Inference
#26This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way: var list = new ArrayList (); There is no way to infer the type of the generic parameter. So we will go back to doing: var list = new ArrayList (); Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond…
I've been doing List list = new ArrayList (); Isn't that good enough?
The List is almost as redundant as the RHS was.
Re: JEP 286: Local-Variable Type Inference
#27Cool, this will help Java from looking so bad: https://gist.github.com/mythz/7e263820332a0fcea766 From Java LINQ Examples: https://github.com/mythz/java-linq-examples
Re: JEP 286: Local-Variable Type Inference
#28This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way: var list = new ArrayList (); There is no way to infer the type of the generic parameter. So we will go back to doing: var list = new ArrayList (); Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond…
I've been doing List list = new ArrayList (); Isn't that good enough?
var stream = list.stream(); // infers Stream
How would you write it in order to take advantage of type inference?Re: JEP 286: Local-Variable Type Inference
#29This would definitely be a nice language feature to see in Java. It's one (of many) of the reasons I'm attracted to Kotlin ( https://kotlinlang.org/ ).
Re: JEP 286: Local-Variable Type Inference
#30Hey look, it's something else that's been implemented in almost every other JVM language that hasn't made it into Java yet.
Being conservative about what you add to the language is a feature, not a bug. Not all languages need to be on the cutting edge (even if I personally prefer the languages that are)