6 ms·
Seems to be an unpopular opinion, but I don't like or want type inference. All that happens is instead of seeing int result = someFunc() you see val resu
by RyanZAG 11y ago
Seems to be an unpopular opinion, but I don't like or want type inference. All that happens is instead of seeing
int result = someFunc()
you see
val result = someFunc()
Is anything really gained other than saving a couple obvious (and compiler checked) keystrokes? And you've lost the ability to see the type of each variable locally in the function. It's never seemed very useful to me.
- pmahoney 11y agoWell, what about something like: ArrayBlockingQueue<Work> q = new ArrayBlockingQueue<Work>(10)
- RyanZAG 11y agoWould be more like BlockingQueue<Work> q = new ArrayBlockingQueue<>(10) right? You'd use the interface type that you'd want to be working on, so you could replace the ArrayBlockingQueue if needed and be sure you're not using any specific functions. Still seems better than having a 'val' in there, since it signals exactly what aspect of the object you're using. Plus now the compiler will complain if you change ArrayBlockingQueue to something that isn't a queue. I just don't really see the benefit - so what if it saves a couple keystrokes? I don't think I've ever run out of keystrokes before... Meanwhile if it saves a single logic error or helps the compiler detect a mistake, then it's saved a lot of real effort.
- unwind 11y agoFor your example, sure. But it's not uncommon (in my opinion) to write stuff like EnumMap<FooEnum, BarClass> map = new EnumMap<FooEnum, BarClass>(FooEnum.class); which to me ought to read something like var map = new EnumMap<FooEnum, BarClass>(); Of course, I don't do a lot of Java programming these days and perhaps my first example is simply broken due to ignorance. When I wrote something very similiar to that last week, I failed to figure out how to avoid repeating the type signature, and was annoyed.
- michaelt 11y agoIt's not quite as short as you'd like, but since Java 7 came out in 2011, it's been possible to write: EnumMap<FooEnum, BarClass> map = new EnumMap<>(FooEnum.class); using the "diamond operator" [1]. In fact, my IDE even provides automatic hints to make use of it! With that said, I do think java has too much pro-long-method-and-variable-name culture. [1] http://www.javaworld.com/article/2074080/core-java/jdk-7--the-diamond-operator.html http://www.javaworld.com/article/2074080/core-java/jdk-7--th...
- glogla 11y agoYou can already do something similar, instead you write Map<SomeComplexTypes> map = new HashMap<>();
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- anton_gogolev 11y agoWhen one has functions named "someFunc()", there are bigger problems than being afraid of type inference. I know this is just an example, but if you actually came up with something more realistic, you would have seen that your issue is actually a non-issue.
- jimbobimbo 11y agoPeople like to bring this example up in .NET world. The usual recommendation is to actually have a type on the left hand side, if the right hand side is a function call. int result = doSomething(); but var result = new Dictionary<string, int>(); Type inference really shines once you get into evolved lambdas and generics.
- angersock 11y agoIt's payback for saddling JavaScript with algol-style syntax. The wheel turns.
- ionised 11y agoAgreed. We had a developer here that used 'val' from lombok all over the place and it was irritating. The team made a collective decision to go through and eliminate this from the code base after he left. I don't want any of this in our code.