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.
Comments
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.