private vals in traits depend on composition order #261

scabug · 2007-12-01T07:04:01Z

(From [http://www.nabble.com/private-vals-in-traits--t4780372.html this mailing list thread])

Consider:

 trait A { val foo: String = "A" }
 trait B {
   private val foo: String = "B"
   def f = println(foo)
 }
 object Test extends Application with B with A {
   println(foo) // prints "A", as expected
   f            // prints "B", as expected
 }

This looks, good, but if I switch the order of B and A in the
declaration of Test, it doesn't compile, claiming that there's no such
value as foo.

Adriaan pointed out that this works in the interpreter, and I replied:

Interesting. I see now that it works in the interpreter (I hadn't
tried). But it does not work with scalac:

[~]% cat test.scala
trait A { val foo: String = "A" }
trait B {
   private val foo: String = "B"
   def f = println(foo)
}
object Test extends A with B {
   println(foo)
   f
}
[~]% scalac test.scala
test.scala:7: error: not found: value foo
   println(foo)
           ^
one error found
[~]% scalac -version
Scala compiler version 2.6.0-final -- (c) 2002-2007 LAMP/EPFL
[~]% scala
Welcome to Scala version 2.6.0-final.
Type in expressions to have them evaluated.
Type :help for more information.

scala> :load test.scala
Loading test.scala...
defined trait A
defined trait B
defined module Test

scala> Test
A
B
res0: Test.type = Test$$@7b37df

I would expect this to work in the compiler as it works in the interpreter. If this is not a compiler defect, I would also expect it to fail in the interpreter. (The above session is with 2.6.0, but the behavior is the same in 2.6.1-RC1.)

scabug · 2007-12-01T07:04:01Z

Imported From: https://issues.scala-lang.org/browse/SI-261?orig=1
Reporter: Matt Hellige (hellige)
See #7475

scabug · 2007-12-18T14:58:39Z

@michelou said:
Compiler and interpreter should behave the same.

scabug · 2009-01-14T11:54:15Z

@odersky said:
Milestone next_bugfix deleted

scabug · 2009-11-05T07:51:56Z

Jrg Kubitz (jukz) said:
using Eclipse 3.5.1 scala plugin 2.7.7.final, Windows XP
this doesnt work either (may be the same bug):

trait a {
private[this] val a:Int=3
}
trait b {
private[this] val a:Int=3
}
class c extends a with b { //compiler crahses
}

scabug · 2010-07-03T03:19:48Z

@paulp said:
(In r22482) Test case closes #261, no review.

scabug · 2010-07-15T23:22:26Z

Matt Hellige (hellige) said:
I'm sorry, this bug still exists in 2.8 final. If you look carefully at the test case, you will see that it tests the wrong thing!

In the test case, the order of the declarations of A and B are switched between the two versions:

trait A ...
trait B ...

vs

trait B ...
trait A ...

But this has nothing to do with the bug!! The important change is the order of A and B in the declaration of Test:

object Test extends Application with A with B ... 
object Test extends Application with B with A ...  // this one fails!

In 2.8 final, it remains the case that this works correctly in the interpreter, and incorrectly in the compiler. There seems to be no change in behavior since the bug was opened. The original transcript I included when I opened the bug is still what I see with the new release.

Sorry to have to reopen this very old bug!

scabug · 2010-07-15T23:27:26Z

Matt Hellige (hellige) said:

object Test extends Application with A with B ...  // THIS one fails...
object Test extends Application with B with A ...

Sorry for all the confusion, it is actually the first one ("A with B") which fails, as in the original bug. In the test case, both versions have "B with A".

scabug · 2011-01-14T02:05:14Z

@paulp said:
trac has some funny ideas about who to email when; I get tons of pointless emails about people being added to cc lists, but nothing about this ticket being reopened even though I closed it.

That test case is seriously braindamaged. I'm not in the habit of checkin in no-op test cases, don't know what spell I was under.

scabug · 2013-03-15T00:02:55Z

@adriaanm said:
Un-assigning to foster work stealing, as announced in https://groups.google.com/forum/?fromgroups=#!topic/scala-internals/o8WG4plpNkw

scabug · 2013-07-10T22:20:06Z

@adriaanm said:
Unassigning and rescheduling to M6 as previous deadline was missed.

scabug · 2014-01-27T20:17:18Z

@adriaanm said (edited on Jan 27, 2014 8:17:37 PM UTC):
See also slight variation in #7699 (marked as duplicate)

scabug · 2014-02-10T00:54:38Z

@adriaanm said:
Let;s see if Jason's fixes to findMember resolved this one. Otherwise, probably need to bump to 2.12

scabug · 2014-02-12T03:45:57Z

@adriaanm said (edited on Feb 12, 2014 3:51:25 AM UTC):
Yep!! Chalk up another three-digit bug for mr. Zaugg!

Verified to work with scalac from scala/scala#3440.
I'll submit a PR with the test case.

$ pr_dist 3440
$ /Users/adriaan/git/scala-dist/target/universal/stage/bin/scalac /Users/adriaan/Desktop/bugs/t261/Test.scala 
# WOOHOO
$ scalac -version
Scala compiler version 2.11.0-M7 -- Copyright 2002-2013, LAMP/EPFL
$ scalac /Users/adriaan/Desktop/bugs/t261/Test.scala:8: error: value foo in trait B cannot be accessed in object Test
     println(foo)
             ^
one error found

$ cat /Users/adriaan/Desktop/bugs/t261/Test.scala 
trait A { val foo: String = "A" }
trait B {
   private val foo: String = "B"
   def f = println(foo)
}
object Test extends A with B {
   def main(args: Array[String]) = {
     println(foo)
     f
   }
}

$ /Users/adriaan/git/scala-dist/target/universal/stage/bin/scala Test
A
B

PS: https://github.com/adriaanm/binfu/blob/master/scafu.sh#L41

scabug · 2014-02-12T03:59:26Z

@adriaanm said (edited on Feb 12, 2014 3:59:46 AM UTC):
Test in scala/scala#3512

scabug · 2014-02-15T22:26:26Z

Matt Hellige (hellige) said:
Incredible! It almost makes me sad to see this one closed... ;)

scabug closed this as completed Feb 12, 2014

scabug added blocker access has PR labels Apr 6, 2017

scabug added this to the 2.11.0-RC1 milestone Apr 6, 2017

scabug assigned retronym Apr 6, 2017

This was referenced Apr 7, 2017

Private member shadows inherited member #7475

Closed

private members create mixin order dependency #7699

Closed

SethTisue mentioned this issue Oct 9, 2018

Rare combination of mixing traits with annotated values causes an erroneous "inherits conflicting members" error in 2.10 #11190

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

private vals in traits depend on composition order #261

private vals in traits depend on composition order #261

scabug commented Dec 1, 2007

scabug commented Dec 1, 2007

scabug commented Dec 18, 2007

scabug commented Jan 14, 2009

scabug commented Nov 5, 2009

scabug commented Jul 3, 2010

scabug commented Jul 15, 2010

scabug commented Jul 15, 2010

scabug commented Jan 14, 2011

scabug commented Mar 15, 2013

scabug commented Jul 10, 2013

scabug commented Jan 27, 2014

scabug commented Feb 10, 2014

scabug commented Feb 12, 2014

scabug commented Feb 12, 2014

scabug commented Feb 15, 2014

private vals in traits depend on composition order #261

private vals in traits depend on composition order #261

Comments

scabug commented Dec 1, 2007

scabug commented Dec 1, 2007

scabug commented Dec 18, 2007

scabug commented Jan 14, 2009

scabug commented Nov 5, 2009

scabug commented Jul 3, 2010

scabug commented Jul 15, 2010

scabug commented Jul 15, 2010

scabug commented Jan 14, 2011

scabug commented Mar 15, 2013

scabug commented Jul 10, 2013

scabug commented Jan 27, 2014

scabug commented Feb 10, 2014

scabug commented Feb 12, 2014

scabug commented Feb 12, 2014

scabug commented Feb 15, 2014