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

Overloading in package object #1987

Closed
scabug opened this Issue May 16, 2009 · 19 comments

Comments

Projects
None yet
2 participants
@scabug
Copy link

scabug commented May 16, 2009

Trivial overloading resolution in package object doesn't work?

package object overloading {
    def bar(f: (Int) => Unit): Unit = ()
    def bar(f: (Int, Int) => Unit): Unit = ()
}

class PackageObjectOverloadingTest {
    overloading.bar( (i: Int) => () ) // doesn't compile.
}
@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 16, 2009

Imported From: https://issues.scala-lang.org/browse/SI-1987?orig=1
Reporter: @okomok
Other Milestones: 2.10.0
Attachments:

@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 16, 2009

@okomok said:
A failed test

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jun 8, 2009

@dubochet said:
Apparently, package objects do not check if two overloaded methods have same erased parameters.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 7, 2009

@paulp said:
Fixed at some point, test in r18959.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Feb 19, 2010

Erkki Lindpere (villane) said:
There are still bugs with this:

File1:
package bug
package object packageb {
def func(a: Int) = ()
def func(a: String) = ()

}

File2:
package bug.packageb

class Client {
val x = func(1) // type mismatch; found : Int(1) required: String
val y = func("1") // compiles
}

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Feb 19, 2010

Erkki Lindpere (villane) said:
Sorry, I'll repost to make the code easier to read:

File1.scala

package bug

package object packageb {
  def func(a: Int) = ()
  def func(a: String) = ()

}

File2.scala

package bug.packageb

class Client {
  val x = func(1) // doesn't compile: type mismatch; found: Int(1) required: String
  val y = func("1") // compiles
}
@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 10, 2011

Harrison Klaperman (hlklaperman) said:
I can confirm with Scala 2.8.1, Java 1.6.0_20 (64-bit HotSpot).
In one file we have:

package object test {
  def foo(a: Int, b: Int) = a + b
  def foo(a: Int, b: Int, c: Int) = a + b + c
  
  def bar[A, B](a: A, b: B) = (a, b)
  def bar[A, B, C](a: A, b: B, c: C) = (a, b, c)
  
  def baz(a: AnyVal) = a
  def baz(a: String) = a
  def baz(a: Seq[_]) = a
  
  def test1() {
    foo(1, 2)
    foo(1, 2, 3)
    
    bar(1, 2)
    bar(1, 2, 3)
    bar('a', new Object)
    bar('a', new Object, 'a'.asInstanceOf[AnyRef])
    
    baz(5)
    baz("5")
  }  
}

The above file compiles with no errors.

In another file we have the exact same method test1, this time in an object Test:

package test

object Test {
  def test1() {
    foo(1, 2)
    foo(1, 2, 3)
    
    bar(1, 2)
    bar(1, 2, 3)
    bar('a', new Object)
    bar('a', new Object, 'a'.asInstanceOf[AnyRef])
    
    baz(5)
    baz("5")
  }  
}

The compiler reports the following errors:

test2.scala:5: error: not enough arguments for method foo: (a: Int,b: Int,c: Int)Int.
Unspecified value parameter c.
    foo(1, 2)
       ^
test2.scala:8: error: not enough arguments for method bar: (a: A,b: B,c: C)(A, B, C).
Unspecified value parameter c.
    bar(1, 2)
       ^
test2.scala:10: error: not enough arguments for method bar: (a: A,b: B,c: C)(A, B, C).
Unspecified value parameter c.
    bar('a', new Object)
       ^
test2.scala:13: error: type mismatch;
 found   : Int(5)
 required: Seq[_]
    baz(5)
        ^
four errors found

I think this is a pretty big bug in package objects.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 10, 2011

Harrison Klaperman (hlklaperman) said:
I've also reproduced it with Scala 2.9.0 RC4 on the same machine. The compiler does the exact same thing.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 13, 2011

@paulp said:
For an ironic twist, if you're in any package other than "test", then import test._ allows def test1() to compile. But you can't do that import in package test or you are bombarded by ambiguity errors.

./a.scala:30: error: reference to foo is ambiguous;
it is both defined in object test and imported subsequently by 
import test._
      foo(1, 2)
      ^
./a.scala:31: error: reference to foo is ambiguous;
it is both defined in object test and imported subsequently by 
import test._
      foo(1, 2, 3)
      ^

etc.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 15, 2011

@retronym said:
A warning or error would be a really valuable stop-gap until the final design for package objects is done.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jul 7, 2011

Harrison Klaperman (hlklaperman) said:
I was not aware that the design of package objects has not been finalized. Where can I learn more about possible changes or improvements?

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jan 13, 2012

@non said (edited on Jan 13, 2012 6:21:47 AM UTC):
Just ran into this in a really subtle way:

//  package.scala
package foo
package object bar {
  def duh(n:Long) = println("long")
  def duh(n:Double) = println("double")
}
// main.scala
package foo.bar
object Main {
  def main(args:Array[String]) {
    duh(33L)
    foo.bar.duh(33L)
  }
}

Output:

double
long

In the wild it takes a moment to notice that this is going on because the Long values will get coerced into Doubles. Currently scala.math would hit this bug in a big way if it needed to use its own functions (e.g. abs). I noticed this when writing a similar "math package".

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jan 13, 2012

@paulp said:
I'm adding a warning.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jan 13, 2012

@paulp said:
Better yet, fixed in 66a3623d59 .

@scabug scabug closed this Jan 13, 2012

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jan 13, 2012

@non said:
Awesome, thanks so much!

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Aug 22, 2012

Chris (chris) said (edited on Aug 22, 2012 9:54:29 PM UTC):
This fix, present in 2.10-M6 and above can cause the following issue at runtime. Comment added should anyone else hit this.

The code will "compile" but it generates CCEing byte code:

scaley.funny.package$ cannot be cast to scales.xml.PullIteratees

which is true, but for some reason the compiler generates it.

The code is here:

https://github.com/chris-twiner/scalesXml/tree/cdeb3a7e04d15cf77c9fda4d406c3eb403920a18

4 very small files plus the build.sbt. clean + run and you'll see the cce.

I've commented in the code what can stop the cce, any of which forces
the correct package$ to be used:

  • change package name of using code (and import the package)
  • comment out the import of scaley.funny._
  • remove the overloaded function in PullIteratees
  • use the fully qualified path to iterate
@scabug

This comment has been minimized.

Copy link
Author

scabug commented Aug 22, 2012

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Aug 25, 2012

Chris (chris) said:
very cool, many thanks

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Oct 3, 2012

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