4 ms·

The problem is when you get things like: var someLongThing <application.someHierarchy.someLongAssPackage.someLongThing> = new application.someHierarchy.someLon

• hinkley 4y ago
  class class1<T extends Comparable<T> > implements SmallestLargest<T> T[] values; This is a spot where inference doesn't work, but has the same problem as the relatively tame example you used. The solution here is not to eliminate the type signatures. The solution is not to wait until compile time to figure out the type of a thing. Nominal typing, as in named types, is the solution here. If you have a 'thing', which also happens to be an application.someHierarchy.someLongAssPackage.someLongThing implements application.someHierarchy.someLongAssPackage.someInterface, anotherLongAssDefinitionForTheReturnTypes but that's an implementation detail, not a type description. It's an Address, or a customer impression, or a similar product, or a fuel tank. Just fucking call it what it is instead of pretending like you're working on your PhD thesis. Your coworkers aren't robots, or academics, they're human beings who've got real work to do and kissing your architectural astronaut butt/complementing your farts are not on the list. Name things like a human. A wise human, but a human.
• orlp 4y ago
  Not really, that is solved with aliases. The problem really comes to life when using strongly typed generic functions that must be generic over their return type. This most notably occurs with Rust iterators. Try writing out the type of this thing explicitly: let pos_nums = v.iter().map(|s| s.parse::<u64>().unwrap()).filter(|n| n > 0); Hint: you literally can't in current Rust because closures have Voldemort types, you can't name their type. And even if you could, the resulting type would be horrendous.