I work with some old Java code that's a mix of generic-ised and not. Every time I see a method that returns a Collection I want to shout "COLLECTION OF WHAT?!?!".
Comprehending other people's non-generic code is a giant pain in the ass compared to reading code with generics.
A method might return, say, some URIs. These might be represented as URI objects or strings, depending on your preference (in some tighter areas of the code we might use String objects, because URIs can be expensive-ish to create, and we might know for sure that the strings in question are valid). If I have a method called getURIs, does it return URIs or Strings? Should the method be called getURIsAsStrings? Perhaps, but it makes for some pretty awkward (and long) method names.
Even if you do have a sensible naming scheme that makes the return type clear, it's rather beside the point. If I have a choice between relying on coding convention or generics, I know what option I'm going to pick.
Naming conventions are often used as (IMHO) poor substitutions for type systems. A name is for the programmer. A type is for the computer AND the programmer.
Comments
I work with some old Java code that's a mix of generic-ised and not. Every time I see a method that returns a Collection I want to shout "COLLECTION OF WHAT?!?!".
Comprehending other people's non-generic code is a giant pain in the ass compared to reading code with generics.
The method was named something like "getCollectionOfSomething()"? If so, you might want to put some of the blame on the method naming choices.
A method might return, say, some URIs. These might be represented as URI objects or strings, depending on your preference (in some tighter areas of the code we might use String objects, because URIs can be expensive-ish to create, and we might know for sure that the strings in question are valid). If I have a method called getURIs, does it return URIs or Strings? Should the method be called getURIsAsStrings? Perhaps, but it makes for some pretty awkward (and long) method names.
Even if you do have a sensible naming scheme that makes the return type clear, it's rather beside the point. If I have a choice between relying on coding convention or generics, I know what option I'm going to pick.
I'm not arguing the point that generics are unuseful.
But imho the method should not be named for the compiler-type of it's return value (unless it's a type converter like int2string or similar).
It should be named for the bizlogic/semantic type:
So..not "getURIs()", but better "getBackendPoolMembers()" or "getBackendPoolMemberURIs()" if you have more than one way of representing them.
Long method names are fine. Everyone uses autocomplete. Choose good names and rename them often as the meaning of the code changes over time.
That's fair enough - I'm always happy to have descriptive methods names. I still want to know the compiler type of what I'm getting back though.
Naming conventions are often used as (IMHO) poor substitutions for type systems. A name is for the programmer. A type is for the computer AND the programmer.
Generics notwithstanding, Go's slices are typed.
var stuff []MyType