ทำไมคอมไพเลอร์ Scala ไม่อนุญาตให้โอเวอร์โหลดวิธีที่มีอาร์กิวเมนต์เริ่มต้น

ในขณะที่อาจมีกรณีที่ถูกต้องซึ่งวิธีการบรรทุกเกินพิกัดดังกล่าวอาจไม่ชัดเจนทำไมคอมไพเลอร์ไม่อนุญาตรหัสที่ไม่ชัดเจนในเวลารวบรวมหรือเวลาทำงาน?

ตัวอย่าง:

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

มีเหตุผลใดบ้างที่ทำให้ข้อ จำกัด เหล่านี้ไม่สามารถคลายได้บ้าง?

โดยเฉพาะอย่างยิ่งเมื่อทำการแปลงโค้ด Java ที่มีการโอเวอร์โหลดอย่างมากเป็นอาร์กิวเมนต์เริ่มต้นของ Scala นั้นเป็นสิ่งที่สำคัญมากและมันก็ไม่ดีที่จะหาคำตอบหลังจากเปลี่ยนวิธี Java มากมายโดยวิธี Scala หนึ่งวิธีที่ spec / compiler กำหนดข้อ จำกัด โดยพลการ

ฉันต้องการอ้างอิง Lukas Rytz (จากที่นี่ ):

เหตุผลก็คือเราต้องการรูปแบบการตั้งชื่อที่กำหนดไว้สำหรับวิธีการที่สร้างขึ้นซึ่งคืนค่าอาร์กิวเมนต์เริ่มต้น ถ้าคุณเขียน

def f(a: Int = 1)

คอมไพเลอร์สร้าง

def f$default$1 = 1

หากคุณมีสองโอเวอร์โหลดที่มีค่าเริ่มต้นในตำแหน่งพารามิเตอร์เดียวกันเราจะต้องมีรูปแบบการตั้งชื่อที่แตกต่างกัน แต่เราต้องการให้โค้ดไบต์ที่สร้างขึ้นมีความเสถียรในการรันหลายคอมไพเลอร์

วิธีแก้ปัญหาสำหรับรุ่น Scala ในอนาคตอาจรวมชื่อประเภทของอาร์กิวเมนต์ที่ไม่ใช่ค่าเริ่มต้น (ที่จุดเริ่มต้นของวิธีการซึ่งแก้ปัญหารุ่นที่มีการโหลดมากเกินไป) ลงใน schema การตั้งชื่อเช่นในกรณีนี้:

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

มันจะเป็นสิ่งที่ชอบ:

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

มีคนยินดีที่จะเขียนข้อเสนอ SIPหรือไม่

มันจะยากมากที่จะได้ข้อมูลจำเพาะที่อ่านได้และแม่นยำสำหรับการโต้ตอบของการแก้ปัญหาการโหลดมากเกินไปด้วยอาร์กิวเมนต์เริ่มต้น แน่นอนสำหรับหลาย ๆ กรณีเช่นเดียวกับที่นำเสนอที่นี่มันง่ายที่จะพูดว่าควรจะเกิดอะไรขึ้น แต่นั่นยังไม่เพียงพอ เราต้องการสเป็คที่จะตัดสินกรณีมุมที่เป็นไปได้ทั้งหมด การระบุความละเอียดที่มากเกินไปนั้นยากที่จะระบุ การเพิ่มอาร์กิวเมนต์เริ่มต้นในการผสมจะทำให้มันยากขึ้น นั่นเป็นเหตุผลที่เราเลือกที่จะแยกทั้งสองอย่าง

ฉันไม่สามารถตอบคำถามของคุณได้ แต่นี่เป็นวิธีแก้ปัญหา:

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
}

หากคุณมีสองรายการ ARG ที่ยาวมากซึ่งต่างกันใน ARG เพียงอันเดียวมันอาจคุ้มค่ากับปัญหา ...

สิ่งที่ได้ผลสำหรับฉันคือการกำหนดวิธีการโอเวอร์โหลดอีกครั้ง (สไตล์ Java)

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"

สิ่งนี้ทำให้มั่นใจได้ว่าคอมไพเลอร์ต้องการความละเอียดที่คุณต้องการตามพารามิเตอร์ปัจจุบัน

นี่คือลักษณะทั่วไปของ @Landei คำตอบ:

สิ่งที่คุณต้องการ:

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

หนึ่งในสถานการณ์ที่เป็นไปได้คือ

  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

คอมไพเลอร์จะสับสนเกี่ยวกับการที่จะโทร ในการป้องกันอันตรายอื่น ๆ ที่เป็นไปได้คอมไพเลอร์จะอนุญาตวิธีการโอเวอร์โหลดที่มากที่สุดหนึ่งวิธีมีอาร์กิวเมนต์เริ่มต้น

แค่เดาของฉัน :-)

ความเข้าใจของฉันคือว่าสามารถมีการชนกันของชื่อในชั้นเรียนที่คอมไพล์ด้วยค่าอาร์กิวเมนต์เริ่มต้น ฉันเห็นบางสิ่งตามบรรทัดเหล่านี้ที่กล่าวถึงในหลายเธรด

ข้อมูลจำเพาะอาร์กิวเมนต์ที่มีชื่ออยู่ที่นี่: http://www.scala-lang.org/sites/default/files/sids/rytz/Mon,%202009-11-09,%2017:29/named-args.pdf

มันระบุว่า:

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

ดังนั้นสำหรับเวลาที่อัตราใด ๆ ก็จะไม่ทำงาน

คุณสามารถทำสิ่งที่ชอบใน Java เช่น:

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