4 ms·
> 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 =
by namelezz 11y ago
> 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<String> list = new ArrayList<>(); // (1)
var list = new ArrayList<String>(); // (2)
Many would say List<String> in (1) is redundant but I would argue otherwise. The intention of List<String> in (1) is to reference to the underline ArrayList through List interface. (1) is trying to encourage programming to an interface while (2) just completely destroys the practice by inferring the type for list variable to be ArrayList<String>. That means subsequent method invocations after (2) can be methods from ArrayList not List.
- haffla 11y agoYou 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.
- nikolay 11y agoOptional, alright, but promoting bad practices. If people like dumb-down languages, there are plenty of them already!
- oldmanjay 11y agoWhat 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.
- nikolay 11y agoThe best practice is that the type of the variable is of the interface, not the implementation except in some special cases.
- wtetzner 11y agoSo stop using constructors and start using static factory methods. The return type of a static factory method can be the interface type.
- nikolay 11y agoYeah, 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!
- msbarnett 11y agoThis 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.
- oldmanjay 11y agoAs 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.
- nikolay 11y agoI agree. "var" as proposed is dumbing down Java. If there's an intelligent way to infer the interface, not the implementation, then I'd accept it, but otherwise, it's the JavaScriptification if Java given most IDEs can autocomplete this and let you correct if they assume wrongly.
- oldmanjay 11y agoIf you can explain the value of restricting a local initialized with a new instance being inferred to be an interface type, you'll have a point. You won't be able to, because there is literally no point since the constructor must be statically referenced anyway, but I'd love to see you try.
- echelon 11y agoHave you never Map<Shard, ListenableFuture<RpcEndpointResult>>? 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.