Why "avoid method overloading"?

Why does Jorge Ortiz advise to avoid method overloading?


Overloading makes it a little harder to lift a method to a function:

object A {
   def foo(a: Int) = 0
   def foo(b: Boolean) = 0
   def foo(a: Int, b: Int) = 0

   val function = foo _ // fails, must use = foo(_, _) or (a: Int) => foo(a)

You cannot selectively import one of a set of overloaded methods.

There is a greater chance that ambiguity will arise when trying to apply implicit views to adapt the arguments to the parameter types:

scala> implicit def S2B(s: String) = !s.isEmpty                             
S2B: (s: String)Boolean

scala> implicit def S2I(s: String) = s.length                               
S2I: (s: String)Int

scala> object test { def foo(a: Int) = 0; def foo(b: Boolean) = 1; foo("") }
<console>:15: error: ambiguous reference to overloaded definition,
both method foo in object test of type (b: Boolean)Int
and  method foo in object test of type (a: Int)Int
match argument types (java.lang.String)
       object test { def foo(a: Int) = 0; def foo(b: Boolean) = 1; foo("") }

It can quietly render default parameters unusable:

object test { 
    def foo(a: Int) = 0; 
    def foo(a: Int, b: Int = 0) = 1 

Individually, these reasons don't compel you to completely shun overloading. I feel like I'm missing some bigger problems.


The evidence is stacking up.


  • You can't (currently) use overloaded methods in package objects.
  • Applicability errors are harder to diagnose for callers of your API.


  • static overload resolution can rob an API of all type safety:
scala> object O { def apply[T](ts: T*) = (); def apply(f: (String => Int)) = () }
defined object O

scala> O((i: String) => f(i)) // oops, I meant to call the second overload but someone changed the return type of `f` when I wasn't looking...

The reasons that Gilad and Jason (retronym) give are all very good reasons to avoid overloading if possible. Gilad's reasons focus on why overloading is problematic in general, whereas Jason's reasons focus on why it's problematic in the context of other Scala features.

To Jason's list, I would add that overloading interacts poorly with type inference. Consider:

val x = ...

A change in the inferred type of x could alter which foo method gets called. The value of x need not change, just the inferred type of x, which could happen for all sorts of reasons.

For all of the reasons given (and a few more I'm sure I'm forgetting), I think method overloading should be used as sparingly as possible.

I think the advice is not meant for scala especially, but for OO in general (so far I know scala is supposed to be a best-of-breed between OO and functional).

Overriding is fine, it's the heart of polymorphism and is central to OO design.

Overloading on the other hand is more problematic. With method overloading it's hard to discern which method will be really invoked and it's indeed a frequently a source of confusion. There is also rarely a justification why overloading is really necessary. The problem can most of the time be solved another way and I agree that overloading is a smell.

Here is an article that explain nicely what I mean with "overloading is a source of confusion", which I think is the prime reason why it's discouraged. It's for java but I think it applies to scala as well.

Need Your Help

ScheduledExecutorService - Check if scheduled task has already been completed

java multithreading timer singleton

I have a server side application where clients can request to reload the configuration. If a client request to reload the configuration, this should not be done immediately, but with an delay of 1 ...

How do I "copy unless later version exists" in Capistrano?

ruby-on-rails ruby security deployment capistrano

I want to protect my database.yml file by keeping it out of version control. Thus, I have two tasks in my Capistrano deploy recipe: