Чому «уникати перевантаження методів»?

Чому Хорхе Ортіс радить уникати перевантаження методів?

Перевантаження набагато ускладнює підняття методу до функції:

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)
}

Ви не можете вибірково імпортувати один із набору перевантажених методів.

Існує більша ймовірність виникнення неоднозначності при спробі застосувати неявні погляди для адаптації аргументів до типів параметрів:

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("") }

Він може тихо зробити параметри за замовчуванням непридатними:

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

В індивідуальному порядку ці причини не змушують вас повністю уникати перевантажень. Я відчуваю, що мені не вистачає деяких більших проблем.

ОНОВЛЕННЯ

Докази складаються.

• Це ускладнює специфікацію
• Це може зробити імпліцити непридатними для використання в межах зору перегляду.
• Це обмежує вам запровадження стандартних параметрів лише для однієї з перевантажених альтернатив.
• Оскільки аргументи будуть набиратися без очікуваного типу, ви не можете передавати анонімні літерали функцій, такі як '_.foo', як аргументи для перевантажених методів .

ОНОВЛЕННЯ 2

• Ви не можете (наразі) використовувати перевантажені методи в об’єктах пакета.
• Помилки застосовності важче діагностувати для абонентів вашого API.

ОНОВЛЕННЯ 3

• статичне дозвіл на перевантаження може позбавити API будь-якого типу безпеки:

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

Причини, які наводять Гілад та Джейсон (ретронім), є дуже вагомими причинами, щоб уникнути перевантажень, якщо це можливо. Причини Гілада зосереджені на тому, чому перевантаження загалом проблематично, тоді як причини Джейсона зосереджені на тому, чому це проблематично в контексті інших особливостей Scala.

До списку Джейсона я б додав, що перевантаження погано взаємодіє з висновками типу. Розглянемо:

val x = ...
foo(x)

Зміна виведеного типу xможе змінити fooметод, який викликається. Значення з xнеобхідності не зміниться, тільки виведений типу x, який може статися з різних причин.

З усіх наведених причин (і ще кількох, я впевнений, що забуваю), я думаю, що перевантаження методів слід застосовувати якомога економніше.

Я думаю, що поради призначені не для Scala, а для ОО взагалі (поки що я знаю, що Scala повинна бути найкращою у своїй породі між OO та функціоналом).

Перевизначення - це нормально, це серце поліморфізму і є головним у дизайні ОО.

З іншого боку, перевантаження є більш проблематичним. З перевантаженням методів важко зрозуміти, який метод буде справді викликаний, і це справді часто викликає плутанину. Також рідко можна виправдати, чому перевантаження дійсно необхідні. Здебільшого проблему можна вирішити іншим способом, і я згоден, що перевантаження - це запах.

Ось стаття, яка чудово пояснює, що я маю на увазі під назвою "перевантаження - це джерело плутанини", що, на мою думку, є основною причиною, чому це не рекомендується. Це для Java, але я думаю, що це стосується і Scala.