New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot overload applyDynamic #6355
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6355?orig=1 |
@gkossakowski said: Is this really critical bug? I'd call it just known limitation but far from critical. |
@harrah said: For overloading being potentially desirable, I figured that the straightforward design of having an actual ApplyDynamic interface with a fixed signature like: trait ApplyDynamic {
def applyDynamic(name: String, a: Any*)
} was because it was deemed useful to be able to fix the number of arguments and use specific types for the parameters, like: def applyDynamic(name: String, a: Int, b: Double) because the compiler will then check whether a call is applicable as usual, saving the applyDynamic author some of the work of checking argument count, types, and giving names to arguments. So, assuming fixing the parameter count and types is considered useful and given that Scala supports overloading, it seemed odd to have an inconsistency with the rest of Scala here. Otherwise, why not just define and require the ApplyDynamic interface above? I didn't mark it as critical, but if there is anything critical about it, I'd guess it might be a decision on what to do, since that could require incompatible changes. |
@odersky said (edited by @gkossakowski on Sep 22, 2012 9:17:38 AM UTC): x.foo(y)(z) it seems more regular to map to x.applyDynamic("foo")(y)(z) than to x.applyDynamic("foo", y)(z) About overloading conflicts being detected early, it's not so simple, and we generally don't do that for any overloaded method. E.g. |
@odersky said: |
@odersky said: |
@odersky said: |
@gkossakowski said: I'll rewrite your comment using code tag. I discovered a few more issues with the parser trying to write this comment. Yet another reason to dump JIRA the first time we can... |
@retronym said (edited on Sep 22, 2012 9:44:11 AM UTC): |
@harrah said: import language.dynamics
object J {
class X(i: Int) extends Dynamic {
def applyDynamic(name: String)(i: Int): Double = i + 0.5
def applyDynamic(name: String)(i: String): String = "i: " + i.toString
}
val x = new X(3)
val y1: String = x.call("adsf")
val y2: Double = x.call(3)
}
|
@paulp said: |
@harrah said: |
@paulp said: |
@retronym said: |
@harrah said: |
@paulp said: |
@paulp said: import scala.language.dynamics
class A extends Dynamic {
def applyDynamic[T1](method: String)(x1: T1): Any = 1
def applyDynamic[T1, T2](method: String)(x: T1, y: T2): Any = 2
}
object Test {
def main(args: Array[String]): Unit = {
val x = new A
println(x[Int](5))
println(x[Int, String](5, "a"))
}
} However, I hope this causes people reconsider whether the overloading-hostile structure of applyDynamic makes sense. I think this shows that it does not. With no way to express a variable-length type parameter list, we have again, following in the footsteps of structural types, created a pseudo-general mechanism which is incapable by design of being used in common situations for which it would otherwise be useful, creating unnecessary surprises and friction. There is no way to write a dynamic method which can receive every application of a method name. You could push the above out to N type parameters, but then there's no way to avoid explicit type application. |
@xeno-by said: 02:00 ~/Projects/Master/sandbox (master)$ cat Test.scala
import scala.language.dynamics
class A extends Dynamic {
def applyDynamic(method: String): B = new B(method)
}
class B(method: String) {
def apply(x: Int) = s"$method(x: Int)"
def apply(x: String) = s"$method(x: String)"
}
object Test {
def main(args: Array[String]): Unit = {
val x = new A
println(x.bippy(42))
println(x.bippy("42"))
}
}
02:00 ~/Projects/Master/sandbox (master)$ scalac Test.scala && scala Test
bippy(x: Int)
bippy(x: String) |
@paulp said: |
@xeno-by said: |
It is not possible to overload applyDynamic because the name parameter is required to be by itself in the first parameter list:
The text was updated successfully, but these errors were encountered: