Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Overloading makes it a little harder to lift a method to a function:</p> <pre><code>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) =&gt; foo(a) } </code></pre> <p>You cannot selectively import one of a set of overloaded methods.</p> <p>There is a greater chance that ambiguity will arise when trying to apply implicit views to adapt the arguments to the parameter types:</p> <pre><code>scala&gt; implicit def S2B(s: String) = !s.isEmpty S2B: (s: String)Boolean scala&gt; implicit def S2I(s: String) = s.length S2I: (s: String)Int scala&gt; object test { def foo(a: Int) = 0; def foo(b: Boolean) = 1; foo("") } &lt;console&gt;: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("") } </code></pre> <p>It can quietly render default parameters unusable:</p> <pre><code>object test { def foo(a: Int) = 0; def foo(a: Int, b: Int = 0) = 1 } </code></pre> <p>Individually, these reasons don't compel you to completely shun overloading. I feel like I'm missing some bigger problems.</p> <p><strong>UPDATE</strong></p> <p>The evidence is stacking up.</p> <ul> <li>It complicates the <a href="http://lampsvn.epfl.ch/trac/scala/ticket/3595" rel="nofollow noreferrer">spec</a></li> <li>It can <a href="https://lampsvn.epfl.ch/trac/scala/ticket/3688" rel="nofollow noreferrer">render implicits unsuitable</a> for use in view bounds.</li> <li>It limits you to introduce defaults for parameters on only one of the overloaded alternatives.</li> <li>Because the arguments will be typed without an expected type, you can't pass anonymous function literals like <a href="https://stackoverflow.com/questions/3315752/why-does-scala-type-inference-fail-here/3316091#3316091">'_.foo' as arguments to overloaded methods</a>.</li> </ul> <p><strong>UPDATE 2</strong></p> <ul> <li>You can't (currently) use overloaded methods in package objects.</li> <li>Applicability errors are <a href="http://gridgaintech.wordpress.com/2010/11/01/scala-compiler-error-no-wonder-some-folks-are-giving-up/" rel="nofollow noreferrer">harder to diagnose</a> for callers of your API.</li> </ul> <p><strong>UPDATE 3</strong></p> <ul> <li>static overload resolution can rob an API of all type safety:</li> </ul> <pre><code>scala&gt; object O { def apply[T](ts: T*) = (); def apply(f: (String =&gt; Int)) = () } defined object O scala&gt; O((i: String) =&gt; f(i)) // oops, I meant to call the second overload but someone changed the return type of `f` when I wasn't looking... </code></pre>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload