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

111–120 of 132 posts

Re: JEP 286: Local-Variable Type Inference

#111

Post by oldmanjay »

oldmanjay wrote: post #70
nikolay wrote: post #51

Earlier quoted context omitted.

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

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.

As the sibling comment indicates, and I wish to amplify with precision, if you are using the static constructor reference to initialize the local, declaring the local reference to be of a super type is cargo cult nonsense, not a best practice. The concrete type is already locally known, nothing is gained via the abstraction.

Re: JEP 286: Local-Variable Type Inference

#112

Post by dllthomas »

zZorgz wrote: post #87
dllthomas wrote: post #85

Earlier quoted context omitted.

> I think deciding what to allow and prohibit by default is an important design decision. I don't think I disagree with that, but I don't think it was made wrong here. It's true that you "risk the chance" of reading unannotated code, but I find there are times when the code I need to write is clearer to me than the type it'll have, and being able to defer annotation past compilation is occasionally a big win and ofte…

My own experience is that I've been running into less scenarios where I think omitting the type makes code more readable (coming from Scala). It doesn't help myself and my coworkers that it's easy (or 'lazy') to omit annotations. I often wish I was using a text editor or IDE that understood my code and could insert type annotations for me, maybe automatically, and maybe not choose to do so if the line of code would "…

I agree that omitting the type rarely, if ever, makes the code more readable.

But readability can easily matter less than other things over the course of one compile. This is why I think the best choice is demanding top level annotations for reasonably complete code (say, every commit) and not doing so before I can ask for the shape of something, or see that it outputs what I thought, or run my tests, or see what type errors I get elsewhere.

It might be marginally better to demand it by default and have a flag to disable the check. Demanding it always is more than marginally worse (which is not to say it's the end of the world - it's totally not).

Re: JEP 286: Local-Variable Type Inference

#113

Post by msbarnett »

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.

This is complete nonsense if you're using a static constructor and not a factory. There's zero point to doing this for a local, statically constructed type. It's not a best practice.

If you were using a factory, var would infer the factory signature's type, which would normally be the interface.

Re: JEP 286: Local-Variable Type Inference

#114

Post by zZorgz »

dllthomas wrote: post #112
zZorgz wrote: post #87

Earlier quoted context omitted.

My own experience is that I've been running into less scenarios where I think omitting the type makes code more readable (coming from Scala). It doesn't help myself and my coworkers that it's easy (or 'lazy') to omit annotations. I often wish I was using a text editor or IDE that understood my code and could insert type annotations for me, maybe automatically, and maybe not choose to do so if the line of code would "…

I agree that omitting the type rarely, if ever, makes the code more readable. But readability can easily matter less than other things over the course of one compile . This is why I think the best choice is demanding top level annotations for reasonably complete code (say, every commit) and not doing so before I can ask for the shape of something, or see that it outputs what I thought, or run my tests, or see what ty…

Yeah, when the effort put into inserting types is higher cost than reading them (as with short lived / unstablized code), what you're saying makes sense.

Which is kind of why I wish for tooling outside the compiler to make the effort in specifying types (when it increases readability, maybe based on heuristics) very minimal. Wishful thinking.

Re: JEP 286: Local-Variable Type Inference

#115

Post by dllthomas »

zZorgz wrote: post #114
dllthomas wrote: post #112

Earlier quoted context omitted.

I agree that omitting the type rarely, if ever, makes the code more readable. But readability can easily matter less than other things over the course of one compile . This is why I think the best choice is demanding top level annotations for reasonably complete code (say, every commit) and not doing so before I can ask for the shape of something, or see that it outputs what I thought, or run my tests, or see what ty…

Yeah, when the effort put into inserting types is higher cost than reading them (as with short lived / unstablized code), what you're saying makes sense. Which is kind of why I wish for tooling outside the compiler to make the effort in specifying types (when it increases readability, maybe based on heuristics) very minimal. Wishful thinking.

Well, the warning from ghc gives you the inferred type, which can be helpful. Copying it in place blindly is not advised - it won't break, but something more specific might be better. And of course the compiler has no way of getting inferring what choice of type aliases will be most (correctly) communicative.

Re: JEP 286: Local-Variable Type Inference

#116

Post by incepted »

skippytheroo wrote: post #97
incepted wrote: post #81

Earlier quoted context omitted.

If Groovy rocks your world, wait until you meet Kotlin...

If Kotlin rocks your world, wait until you meet the Scala.

I met Scala a few years ago, we had some fun together but she's way too high maintenance.

Re: JEP 286: Local-Variable Type Inference

#117

Post by wmu »

icebraining wrote: post #100
wmu wrote: post #94

Earlier quoted context omitted.

I totally agree, type inference speed writing a code, nothing more. For easy cases reading such code is OK (var path = "/usr/bin/whatever" - obvious), but with a more complex code it becomes awful. I'm a C++ programmer, and quite often I have to dig through dozens of headers to find out what this magic "auto" really means.

That's because C++ combines type inference with a gnarly compilation process. In a language like Java, editors will support it and you'll just be able to "mouse over" (or press a key combo in Vim/Emacs) and it'll tell you the inferred type.

A good point, I didn't consider IDE support.

Re: JEP 286: Local-Variable Type Inference

#118

Post by nikolay »

msbarnett wrote: post #113
nikolay wrote: post #96

Earlier quoted context omitted.

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

This is complete nonsense if you're using a static constructor and not a factory. There's zero point to doing this for a local, statically constructed type. It's not a best practice. If you were using a factory, var would infer the factory signature's type, which would normally be the interface.

No, it's not a complete nonsense, no. People abusing Java with overengineering and using factories and other enterprisey design patterns for everything made a lot of people leave the Java land!

Re: JEP 286: Local-Variable Type Inference

#119

Post by nikolay »

wtetzner wrote: post #107
nikolay wrote: post #96

Earlier quoted context omitted.

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.

Yeah, let's UML the hell out of everything to be enterprisey and be Martin Fowler-approved! This is what turned off a lot of people before!

Re: JEP 286: Local-Variable Type Inference

#120

Post by lfowles »

icebraining wrote: post #100
wmu wrote: post #94

Earlier quoted context omitted.

I totally agree, type inference speed writing a code, nothing more. For easy cases reading such code is OK (var path = "/usr/bin/whatever" - obvious), but with a more complex code it becomes awful. I'm a C++ programmer, and quite often I have to dig through dozens of headers to find out what this magic "auto" really means.

That's because C++ combines type inference with a gnarly compilation process. In a language like Java, editors will support it and you'll just be able to "mouse over" (or press a key combo in Vim/Emacs) and it'll tell you the inferred type.

Good C++ IDEs do the same.
Post reply on HN