Overloads with different return types

Brad Abrams picked up on Geoff Appleby’s blog entry about Overloads with different return types.  Personally, I think they are both wrong

Let’s consider these overloads:

(1) Public function Add(ByVal x as int32, ByVal y as Int32) As Int32

(2) Public function Add(ByVal x as double, ByVal y as double) As double


(3) Public function Add(Of T)(ByVal x as T, ByVal y as T) As T


Now if you aren’t convinced by (1) and (2) having different return types, then a(3) should hopefully tip the scales for you.


Overloads should, IMO, return different types where appropiate.  It however should not be used willy nilly


Personally, I think much of this discussion stems from people not using Optional parameters (and some lame languages not having full support for them).  The  usage of Overloads is often to mimic (albeit poorly) optional parameters, and really it should not be abused like that. Instead Optional parameters should be used in those cases as not only does code become easier to maintain, but the “missing” parameters also become more obvious to the caller, and the intellisense list they have to look at becomes a lot simpler.  Overloads on the other hand should be held in reserve for such times as different sets of parameters are required (as shown above).  Taking Brad’s example,

(a) Public Function MyFunc(someParam as String) as MyCustomClass

(b) Public Function MyFunc(someDifferentParam as Type, someParam as String) as MyCustomClass


first, (b) should really be written the other way round,

(b) Public Function MyFunc(someParam as String,  someDifferentParam as Type ) as MyCustomClass


next, (a) and (b) should be merged, especially if the current code in (a) just returns a call to (b)


(c)  Public Function MyFunc(someParam as String,  Optional someDifferentParam as Type =Nothing) as MyCustomClass


the beauty of (c) replacing (a) and (b) 


2 Comments so far

  1.   Kevin Ryall on July 18th, 2005          

    I agree with you about Overloading being most frequently used to simulate ‘real’ optional parameters – at the cost of more lines of code and more opportunity for mistakes (by coding an implementation in more than one overload instead of chaining). Overloading is a valuable technique with many uses, one of which is a clumsy implementation of optional parameters in those languages that don’t have them…

    For some reason however, optional parameters are often dismissed as somehow less ‘object oriented’ than overloading – maybe because VB provides them while ‘real’ languages like C# and Java don’t?

    I’m not so sure about returning different types from overloaded methods though – while I agree that it makes sense in some cases, it has great potential for confusion if used unwisely. Our coding standards have always disallowed this – maybe they are too strict, although no-one has complained so far…

  2.   Bill McCarthy on July 18th, 2005          

    Hey Kevin,

    I think you’re right on both counts

    The need for returning different types is rare.

    As to other languages nto getting the big picture, yes sadly that is true. It’s kind of funy to hear a lot of them talk about dynamic languages as if it’s somethign new, when it’s something VB always has had. Let’s hope that one day languages like C# will finally catch up there, then the only hurdle will be to educate the users of that language