- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Volatile type problem
Wed, 2011-12-21, 19:54
Hi all,
I'm struggling with a volatile type problem which I don't quite understand. I read about it on the SLS but still cannot decipher it.Here is a sample code which exhibits my problem
object TypeTest {
trait A { type N <: NLike type M <: N with MLike trait NLike trait MLike extends NLike } trait B extends A { type N <: MyBNLike trait MyBNLike extends NLike } trait C extends A { type N <: MyCNLike type M <: N with MyCMLike trait MyCNLike extends NLike trait MyCMLike extends MyCNLike with MLike { def implementMe: String //if you take this away, everything compiles } } trait D extends A with B with C { // If I dont mix C it works. type N = NLike with MyBNLike with MyCNLike }}
the compiler error is
overriding type M in trait A with bounds >: Nothing <: C.this.N with C.this.MLike; type M is a volatile type; cannot override a type with non-volatile upper bound type M <: N with MyCMLike
According to what I understood (which probably is wrong anyway) from the SLS, N in trait A should be declared with a volatile upperbound type, so that others can override it with more volatile types, but I can't figure out how to make it volatile.
Which is the right path to achieve something like the above?
Thanks, cheers.
I'm struggling with a volatile type problem which I don't quite understand. I read about it on the SLS but still cannot decipher it.Here is a sample code which exhibits my problem
object TypeTest {
trait A { type N <: NLike type M <: N with MLike trait NLike trait MLike extends NLike } trait B extends A { type N <: MyBNLike trait MyBNLike extends NLike } trait C extends A { type N <: MyCNLike type M <: N with MyCMLike trait MyCNLike extends NLike trait MyCMLike extends MyCNLike with MLike { def implementMe: String //if you take this away, everything compiles } } trait D extends A with B with C { // If I dont mix C it works. type N = NLike with MyBNLike with MyCNLike }}
the compiler error is
overriding type M in trait A with bounds >: Nothing <: C.this.N with C.this.MLike; type M is a volatile type; cannot override a type with non-volatile upper bound type M <: N with MyCMLike
According to what I understood (which probably is wrong anyway) from the SLS, N in trait A should be declared with a volatile upperbound type, so that others can override it with more volatile types, but I can't figure out how to make it volatile.
Which is the right path to achieve something like the above?
Thanks, cheers.
Wed, 2011-12-21, 21:01
#2
Re: Volatile type problem
Ok, nevermind, I solved it.
On Wed, Dec 21, 2011 at 5:11 PM, Rodrigo Cano <ioniviil@gmail.com> wrote:
On Wed, Dec 21, 2011 at 5:11 PM, Rodrigo Cano <ioniviil@gmail.com> wrote:
Sorry I messed up above, its C which doesn't compile with the above error. You can ignore D.
On Wed, Dec 21, 2011 at 4:54 PM, Rodrigo Cano <ioniviil@gmail.com> wrote:
Hi all,
I'm struggling with a volatile type problem which I don't quite understand. I read about it on the SLS but still cannot decipher it. Here is a sample code which exhibits my problem
object TypeTest {
trait A { type N <: NLike type M <: N with MLike trait NLike trait MLike extends NLike } trait B extends A { type N <: MyBNLike trait MyBNLike extends NLike } trait C extends A { type N <: MyCNLike type M <: N with MyCMLike trait MyCNLike extends NLike trait MyCMLike extends MyCNLike with MLike { def implementMe: String //if you take this away, everything compiles } } trait D extends A with B with C { // If I dont mix C it works. type N = NLike with MyBNLike with MyCNLike }}
the compiler error is
overriding type M in trait A with bounds >: Nothing <: C.this.N with C.this.MLike; type M is a volatile type; cannot override a type with non-volatile upper bound type M <: N with MyCMLike
According to what I understood (which probably is wrong anyway) from the SLS, N in trait A should be declared with a volatile upperbound type, so that others can override it with more volatile types, but I can't figure out how to make it volatile.
Which is the right path to achieve something like the above?
Thanks, cheers.
On Wed, Dec 21, 2011 at 4:54 PM, Rodrigo Cano <ioniviil@gmail.com> wrote: