Potential package object bug

The problem is that there can be name conflicts in package object members.
Assume you have to .jar files in your classpath which both define a packageobject `foo':
lib1.jar: package object foo { def show(): Unit = [implementation 1] }lib2.jar: package object foo { def show(): Unit = [implementation 2] }
when loading the packages, the scala compiler has to deal with that conflict.

Right now (SymbolLoaders.scala, def openPackageObjectModule), whenentering a package object member (`show;) into the package, the scalacompiler first removes all existing members of the package named `show'.
It does not try to find out wether the two are valid overloads. The oneentered later wins.

So what happens in your example
package object foo extends ints with shorts
first the members of `ints' are entered into the package `foo' def show(i : Int) = println(i)
then, the members of `shorts' are entered def show(s : Short) = println(s)
when entering the second `show', the first one is unlinked.

Cheers: Lukas

On Mon, Jan 11, 2010 at 01:22, Nick Partridge <nkpart@gmail.com> wrote:

I've been converting some normal objects over to package objects, and
I hit up a strange compile error.

Details are here: http://gist.github.com/273863

plain-object.scala compiles fine, but compiling package-object.scala
it complains that the type of show is Short->Unit not Int->Unit. It
seems to me like the method show in the 'ints' trait is just being
replaced by the 'shorts' trait. Not sure how much sense that makes.

Tested on latest trunk, fails in the same way on the latest RC.

Hi,
I have got a similar problem (below and thread "Bug or feature related to overloaded methods with implicit parameters" at scala-user).
Now the question is, whether this is a bug or a "feature"? I do not know the spec, but IMHO overloading has to work for package object members, i.e. this is a bug.
Heiko
package foo {
  package object bar {      def interfaces[I1, I2](implicit manifest1: Manifest[I1], manifest2: Manifest[I2]) =       (Some(manifest1.erasure.asInstanceOf[Class[I1]]),       Some(manifest2.erasure.asInstanceOf[Class[I2]]))      def interfaces[I1, I2, I3](implicit manifest1: Manifest[I1], manifest2: Manifest[I2], manifest3: Manifest[I3]) =       (Some(manifest1.erasure.asInstanceOf[Class[I1]]),       Some(manifest2.erasure.asInstanceOf[Class[I2]]),       Some(manifest3.erasure.asInstanceOf[Class[I3]]))  }
  package bar {    class Error {      interfaces[String, String]    }  }}
will fail:tmp$ ~/dev/scala/2.8/bin/scalac a.scala  a.scala:17: error: wrong number of type parameters for method interfaces: [I1,I2,I3](implicit manifest1: Manifest[I1],implicit manifest2: Manifest[I2],implicit manifest3: Manifest[I3])(Some[Class[I1]], Some[Class[I2]], Some[Class[I3]])       interfaces[String, String]

2010/1/11 Lukas Rytz <lukas.rytz@epfl.ch>

The problem is that there can be name conflicts in package object members.
Assume you have to .jar files in your classpath which both define a packageobject `foo':
lib1.jar: package object foo { def show(): Unit = [implementation 1] }lib2.jar: package object foo { def show(): Unit = [implementation 2] }
when loading the packages, the scala compiler has to deal with that conflict.

Right now (SymbolLoaders.scala, def openPackageObjectModule), whenentering a package object member (`show;) into the package, the scalacompiler first removes all existing members of the package named `show'.
It does not try to find out wether the two are valid overloads. The oneentered later wins.

So what happens in your example
package object foo extends ints with shorts
first the members of `ints' are entered into the package `foo' def show(i : Int) = println(i)
then, the members of `shorts' are entered def show(s : Short) = println(s)
when entering the second `show', the first one is unlinked.

Cheers: Lukas

On Mon, Jan 11, 2010 at 01:22, Nick Partridge <nkpart@gmail.com> wrote:

I've been converting some normal objects over to package objects, and
I hit up a strange compile error.

Details are here: http://gist.github.com/273863

plain-object.scala compiles fine, but compiling package-object.scala
it complains that the type of show is Short->Unit not Int->Unit. It
seems to me like the method show in the 'ints' trait is just being
replaced by the 'shorts' trait. Not sure how much sense that makes.

Tested on latest trunk, fails in the same way on the latest RC.

--
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

On Wed, Jan 13, 2010 at 7:22 PM, Heiko Seeberger
wrote:
> Hi,
> I have got a similar problem (below and thread "Bug or feature related to
> overloaded methods with implicit parameters" at scala-user).
> Now the question is, whether this is a bug or a "feature"? I do not know
> the spec, but IMHO overloading has to work for package object members, i.e.
> this is a bug.

Missing feature, yes. Package objects are from done yet. Right now
they just provide the minimal functionality for migrating collections.
The rets will come, but it will take some effort, and I'd prefer to do
it in a single design rather than many small increments.

Cheers

Martin,

2010/1/13 martin odersky <martin.odersky@epfl.ch>

Missing feature, yes. Package objects are from done yet. Right now
they just provide the minimal functionality for migrating collections.

Ah, I see. 

The rets will come, but it will take some effort, and I'd prefer to do
it in a single design rather than many small increments.

Sure, NP. Will they be completed within the 2.8 timeframe?
Cheers,
Heiko
My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

On Thu, Jan 14, 2010 at 7:49 AM, Heiko Seeberger
wrote:
> Martin,
>
> 2010/1/13 martin odersky
>>
>> Missing feature, yes. Package objects are from done yet. Right now
>> they just provide the minimal functionality for migrating collections.
>
> Ah, I see.
>
>>
>> The rets will come, but it will take some effort, and I'd prefer to do
>> it in a single design rather than many small increments.
>
> Sure, NP. Will they be completed within the 2.8 timeframe?

I can't commit to that yet. I am not sure I will find the time and
nobody has picked up the ball on this one yet.

Cheers