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

51–60 of 132 posts

Re: JEP 286: Local-Variable Type Inference

#51

Post by nikolay »

haffla wrote: post #49
namelezz wrote: post #33

Earlier quoted context omitted.

> 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…

You fail to see that type inference is optional. So yes for readability's sake, in your first example I wouldn't omit the "int", but in simpler cases you CAN omit if you want. And that's just nice, end of story.

Optional, alright, but promoting bad practices. If people like dumb-down languages, there are plenty of them already!

Re: JEP 286: Local-Variable Type Inference

#52

Post by freekh »

freekh wrote: post #45
incepted wrote: post #38

Earlier quoted context omitted.

> A 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. Type inference has absolutely nothing to do with type safety. Programming languages don't become more or less statically type safe depending on whether they support type inference. Type inferenc…

Hmmm. Yes, you're right. Typesafe is probably the wrong word to describe this according to you and wikipedia :) The problem I tried to describe though is how feasible/typical/normal? it is to catch more or less (type) errors on compile time... Like here, where I basically my point is that it is too hard to use Java's type system to it's full extent because it becomes too cumbersome to actually use it on the callsite.

Puh! Wikipedia also states: 'Type safety is sometimes alternatively considered to be a property of a computer program rather than the language in which that program is written; that is, some languages have type-safe facilities that can be circumvented by programmers who adopt practices that exhibit poor type safety.'.

In (some) Java _programs_ you would circumvent modelling your domain correctly because it would be too cumbersome to use, therefore Java _programs_ tends to be less typesafe... I suppose that is how I use the term and heard it used in my everyday life, e.g. 'this code is more typesafe than that' and so on and so on...

I guess I should have made it more clear that this how I used the word 'typesafe' (though your definition of it is more correct) and underlined that I meant Scala/Java _programs_ not the language (nor the type system) itself.

Still, it is correct that type inference (rather obviously) doesn't have anything to do with type systems.

EDIT: language, clarity

Re: JEP 286: Local-Variable Type Inference

#53

Post by usrusr »

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.

Except when you add final, then there is little reason to have the less specific type.

But i see where you come from, it feels a bit sloppy to not document the intention that the variable _could_ be any kind of list, even though it happens to be an ArrayList. Not "this may lead to nasty bugs"-sloppy, but a slight case of "this won't win any beauty contests"-sloppy.

Re: JEP 286: Local-Variable Type Inference

#54

Post by usrusr »

freekh wrote: post #48
wtetzner wrote: post #41

Earlier quoted context omitted.

I think his argument is that without type inference, programmers will avoid more complex types, and therefor model their domain with less precise types.

Yup :) The comment is valid though: you don't get more type safety because of type inference. Thus saying it gets more typesafe is probably wrong...

The curious case of the broken inverse: you won't get more type safety by having type inference, but you are likely to end up with less type safety when you are not having it ;)

Re: JEP 286: Local-Variable Type Inference

#55

Post by ygra »

merb wrote: post #8

var + val would be great.

I'd find var and val way too easy to confuse. Added to the fact that Java has "effectively final" variables already there should be no need to distinguish here. If anything I'd probably be in favour of "var" and "final var", which would follow existing syntax in the language.

Re: JEP 286: Local-Variable Type Inference

#56

Post by vbezhenar »

Java loses its explicitness with each release. And it's still much worse as a language than Scala, Kotlin, Groovy, Ceylon (and probably always will be behind). I don't see much value in those improvements. If one wants a better Java, he can use it right now. What Java needs is JVM improvements, like value types or full support for bytecode hot reload. Java 1.4 was very minimalistic and beautiful language. I liked it that way.

Re: JEP 286: Local-Variable Type Inference

#57

Post by betimsl »

emmanueloga_ wrote: post #7

I wonder if this JEP draw any inspiration of http://www.eclipse.org/xtend/ . For those new to xtend, think of it as xtend is to java like coffeescript is to javascript. I wish most of the xtend enhancements were integrated to java asap!

Came to write this here. Xtend is amazing for these things.

Re: JEP 286: Local-Variable Type Inference

#60

Post by usrusr »

nikolay wrote: post #47
merb wrote: post #8

var + val would be great.

Yeah, let's spread the nonsense further! There are constants and variables; values are something else. Just because "val" is a short abbreviation everybody gets, it doesn't mean we should abuse it!

Maybe i'm just weird, but to me, when i hear the word "constant" i expect something that is nailed down at compile time.

  final int chosenByFairDiceRoll = 4; // a constant
  final long millis = System.currentTimeMillis(); // not a constant
When you say "values are something else", is it that you would consider chosenByFairDiceRoll a value, but not millis? I guess that you might have had more exposure to languages that use "const" instead of "final" than me...
Post reply on HN