Tại sao trình biên dịch Scala không cho phép các phương thức quá tải với các đối số mặc định?

Mặc dù có thể có các trường hợp hợp lệ khi quá tải phương thức như vậy có thể trở nên mơ hồ, tại sao trình biên dịch không cho phép mã không mơ hồ tại thời gian biên dịch cũng như thời gian chạy?

Thí dụ:

// This fails:
def foo(a: String)(b: Int = 42) = a + b
def foo(a: Int)   (b: Int = 42) = a + b

// This fails, too. Even if there is no position in the argument list,
// where the types are the same.
def foo(a: Int)   (b: Int = 42) = a + b
def foo(a: String)(b: String = "Foo") = a + b

// This is OK:
def foo(a: String)(b: Int) = a + b
def foo(a: Int)   (b: Int = 42) = a + b    

// Even this is OK.
def foo(a: Int)(b: Int) = a + b
def foo(a: Int)(b: String = "Foo") = a + b

val bar = foo(42)_ // This complains obviously ...

Có bất kỳ lý do tại sao những hạn chế này không thể được nới lỏng một chút?

Đặc biệt là khi chuyển đổi mã Java bị quá tải nặng sang các đối số mặc định của Scala là một điều rất quan trọng và thật không hay khi tìm hiểu sau khi thay thế nhiều phương thức Java bằng một phương thức Scala mà trình biên dịch / trình biên dịch áp đặt các hạn chế tùy ý.

Tôi muốn trích dẫn Lukas Rytz (từ đây ):

Lý do là chúng tôi muốn một sơ đồ đặt tên xác định cho các phương thức được tạo để trả về các đối số mặc định. Nếu bạn viết

def f(a: Int = 1)

trình biên dịch tạo ra

def f$default$1 = 1

Nếu bạn có hai tình trạng quá tải với mặc định trên cùng một vị trí tham số, chúng ta sẽ cần một sơ đồ đặt tên khác. Nhưng chúng tôi muốn giữ cho mã byte được tạo ổn định qua nhiều lần chạy trình biên dịch.

Một giải pháp cho phiên bản Scala trong tương lai có thể là kết hợp các tên loại của các đối số không mặc định (các đối số ở đầu phương thức, phân tán các phiên bản quá tải) vào lược đồ đặt tên, ví dụ trong trường hợp này:

def foo(a: String)(b: Int = 42) = a + b
def foo(a: Int)   (b: Int = 42) = a + b

nó sẽ giống như:

def foo$String$default$2 = 42
def foo$Int$default$2 = 42

Ai đó sẵn sàng viết một đề xuất SIP ?

Sẽ rất khó để có được một thông số chính xác và dễ đọc cho các tương tác của quá tải độ phân giải với các đối số mặc định. Tất nhiên, đối với nhiều trường hợp riêng lẻ, như trường hợp được trình bày ở đây, thật dễ dàng để nói điều gì sẽ xảy ra. Nhưng như vậy là chưa đủ. Chúng tôi cần một thông số quyết định tất cả các trường hợp góc có thể. Quá tải độ phân giải đã rất khó để chỉ định. Thêm các đối số mặc định trong hỗn hợp sẽ làm cho nó khó hơn. Đó là lý do tại sao chúng tôi đã chọn cách tách hai.

Tôi không thể trả lời câu hỏi của bạn, nhưng đây là một cách giải quyết:

implicit def left2Either[A,B](a:A):Either[A,B] = Left(a)
implicit def right2Either[A,B](b:B):Either[A,B] = Right(b)

def foo(a: Either[Int, String], b: Int = 42) = a match {
  case Left(i) => i + b
  case Right(s) => s + b
}

Nếu bạn có hai danh sách arg rất dài chỉ khác nhau trong một arg, nó có thể gây rắc rối ...

Điều làm việc cho tôi là xác định lại (kiểu Java) các phương thức nạp chồng.

def foo(a: Int, b: Int) = a + b
def foo(a: Int, b: String) = a + b
def foo(a: Int) = a + "42"
def foo(a: String) = a + "42"

Điều này đảm bảo trình biên dịch độ phân giải bạn muốn theo các tham số hiện tại.

Đây là một khái quát về câu trả lời @Landei:

Những gì bạn thực sự muốn:

def pretty(tree: Tree, showFields: Boolean = false): String = // ...
def pretty(tree: List[Tree], showFields: Boolean = false): String = // ...
def pretty(tree: Option[Tree], showFields: Boolean = false): String = // ...

Workarround

def pretty(input: CanPretty, showFields: Boolean = false): String = {
  input match {
    case TreeCanPretty(tree)       => prettyTree(tree, showFields)
    case ListTreeCanPretty(tree)   => prettyList(tree, showFields)
    case OptionTreeCanPretty(tree) => prettyOption(tree, showFields)
  }
}

sealed trait CanPretty
case class TreeCanPretty(tree: Tree) extends CanPretty
case class ListTreeCanPretty(tree: List[Tree]) extends CanPretty
case class OptionTreeCanPretty(tree: Option[Tree]) extends CanPretty

import scala.language.implicitConversions
implicit def treeCanPretty(tree: Tree): CanPretty = TreeCanPretty(tree)
implicit def listTreeCanPretty(tree: List[Tree]): CanPretty = ListTreeCanPretty(tree)
implicit def optionTreeCanPretty(tree: Option[Tree]): CanPretty = OptionTreeCanPretty(tree)

private def prettyTree(tree: Tree, showFields: Boolean): String = "fun ..."
private def prettyList(tree: List[Tree], showFields: Boolean): String = "fun ..."
private def prettyOption(tree: Option[Tree], showFields: Boolean): String = "fun ..."

Một trong những kịch bản có thể là

  def foo(a: Int)(b: Int = 10)(c: String = "10") = a + b + c
  def foo(a: Int)(b: String = "10")(c: Int = 10) = a + b + c

Trình biên dịch sẽ bị nhầm lẫn về cái nào để gọi. Để ngăn ngừa các nguy hiểm có thể khác, trình biên dịch sẽ cho phép nhiều nhất một phương thức bị quá tải có các đối số mặc định.

Chỉ là phỏng đoán của tôi :-)

Hiểu biết của tôi là có thể có các xung đột tên trong các lớp được biên dịch với các giá trị đối số mặc định. Tôi đã thấy một cái gì đó dọc theo những dòng này được đề cập trong một số chủ đề.

Thông số đối số được đặt tên ở đây: http://www.scala-lang.org/sites/default/files/sids/rytz/Mon,%202009-11-09,%2017:29/named-args.pdf

Nó nói:

 Overloading If there are multiple overloaded alternatives of a method, at most one is
 allowed to specify default arguments.

Vì vậy, tại thời điểm hiện tại, nó sẽ không hoạt động.

Bạn có thể làm một cái gì đó giống như những gì bạn có thể làm trong Java, ví dụ:

def foo(a: String)(b: Int) =  a + (if (b > 0) b else 42)