Skip to content
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

ambiguous reference when importing overloaded functions #2551

Closed
scabug opened this issue Nov 1, 2009 · 3 comments
Closed

ambiguous reference when importing overloaded functions #2551

scabug opened this issue Nov 1, 2009 · 3 comments

Comments

@scabug
Copy link

scabug commented Nov 1, 2009

When importing overloaded functions from two different objects, the compiler generates error when trying to use a function which has the same name regardless of the argument type.

Example:

object DoubleMath {
    def sin(x: Double) = 1
}

object FloatMath {
    def sin(x: String) = 1
}

class A {
    def test() {
        import DoubleMath._
        import FloatMath._

        println(sin(1.0) + sin("1"))
    }
}

Tested on 2.7.7.final and 2.7.3.final with the same result.

error: reference to sin is ambiguous;
it is imported twice in the same scope by
import FloatMath._
and import DoubleMath._
        println(sin(1.0) + sin("1"))

It would be very helpful to import overloaded functions from different objects to enable splitting large libraries into separate files and possibly shipping them in separate jars.

An example of using mass import is when doing mathematics, as you can import all the trigonometric and other standard functions with one statement.

@scabug
Copy link
Author

scabug commented Nov 1, 2009

Imported From: https://issues.scala-lang.org/browse/SI-2551?orig=1
Reporter: @lexn82
Assignee: Evgueni Zouev (zouev)

@scabug
Copy link
Author

scabug commented Nov 3, 2009

Evgueni Zouev (zouev) said:
Remark: qualifying sin's like

DoubleMath.sin(1.0)+FloatMath.sin("1")

solves the problem...

@scabug
Copy link
Author

scabug commented Jun 19, 2010

@odersky said:
No use to micro-tune here. To go further of this we'd need a full new import spec proposal and that's at least a SID. No small thing to do, and nothing the Scala team has the resources for, right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant