Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | SI-6355 SI-7059 it is possible to overload applyDynamic | Eugene Burmako | 2013-12-28 | 1 | -7/+0 |
| | | | | | | | As our discussion at https://issues.scala-lang.org/browse/SI-6355 shows, it looks like it is possible to overload applyDynamic, even though a straightforward way is closed. This commit codifies the pattern proposed by @paulp and makes sure that it doesn’t break in the future. | ||||
* | SI-6355, weakend implementation restriction on applyDynamic. | Paul Phillips | 2013-02-12 | 1 | -2/+5 |
| | | | | | | | | | | | | | | | I realized one can successfully call an overloaded applyDynamic, under conditions such as these: def applyDynamic[T1](m: String)(x1: T1): Any = 1 def applyDynamic[T1, T2](m: String)(x: T1, y: T2): Any = 2 def applyDynamic[T1, T2, T3](m: String)(x: T1, y: T2, z: T3): Any = 3 So I weakened the overloading restriction to allow overloading if each method has a distinct number of type parameters. This very likely still allows the creation of uncallable overloads, but an overly restrictive rule is worse. If the overload cannot be called, it will still be discovered at the call site. | ||||
* | Error for SI-6355, overloading of applyDynamic. | Paul Phillips | 2012-11-14 | 1 | -0/+4 |
As long as it can never be called anyway, seems like we'd be doing people a kindness to fail the compile rather than letting it be ambiguous at every use site. |