scala cake pattern - can I have multiple layers of cake?

Question

so say I have two dependencies in my app, a connection to some pub sub system, and a connection to a database. I can do something like

trait DB {
    def lookup(query:String):String
}

trait PubSub {
    def subscribe(key:String, callback:String => Any)
}

then I can write my logic like

trait Functionality { this:DB with PubSub => 
    def doSomething() {
        val key = lookup("get key")
        subscribe(key, data => println(data))
    }
}

and then my app can be like

object Awesome extends App {

    object repository extends Functionality with DB with PubSub {
        def lookup(query:String) = "some key"
        def subscribe(key:String, callback:String => Any) {
            scala.concurrent.ops.spawn { while(true) { callback(key) ; Thread.Sleep(1000) } } 
        }
    }
    repository.doSomething()
}

and all is well and good in the world.

But what if I want connections to two pub sub systems that share the same database implementation in the same app?

I want to do something like

object Awesome2 extends App {
    object repository extends DB {
        def lookup(query: String): String = "some other key"

        object connection1 extends Functionality with PubSub with DB {
            def subscribe(key: String, callback: (String) => Any) {
                scala.concurrent.ops.spawn { while(true) { callback(key.toUpperCase) ; Thread.sleep(1000) } }
            }
        }

        object connection2 extends Functionality with PubSub with DB {
            def subscribe(key: String, callback: (String) => Any) {
                scala.concurrent.ops.spawn { while(true) { callback(key.toLowerCase) ; Thread.sleep(1000) } }
            }
        }
    }
}

where the objects in the second layer of cake (implicitly?) slurp in the DB implementation from the parent level.

But the scala compiler tells me

error: object creation impossible, since method lookup in trait DB of type (query:String) String is not defined
object connection2 extends Functionality with PubSub with DB {

if I do the following then it does what I want

object Awesome3 extends App {
    object repository extends DB {
        override def lookup(query: String): String = "some other key"

        object connection1 extends Functionality with PubSub with DB {
            def subscribe(key: String, callback: (String) => Any) {
                scala.concurrent.ops.spawn { while(true) { callback(key.toUpperCase) ; Thread.sleep(1000) } }
            }

            def lookup(query: String): String = repository.lookup(query)
        }

        object connection2 extends Functionality with PubSub with DB {
            def subscribe(key: String, callback: (String) => Any) {
                scala.concurrent.ops.spawn { while(true) { callback(key.toLowerCase) ; Thread.sleep(1000) } }
            }

            def lookup(query: String): String = repository.lookup(query)
        }
    }
    repository.connection1.doSomething()
    repository.connection2.doSomething()
}

but this is kind of messy

I can add this trait

trait DB_Base extends DB {

    private val db:DB = this

    trait DB_Layer extends DB {
        def lookup(query:String):String = db.lookup(query)
    }
}

and then the following works

object Awesome4 extends App {
    object repository extends DB_Base {
        override def lookup(query: String): String = "some other key"

        object connection1 extends Functionality with PubSub with DB_Layer {
            def subscribe(key: String, callback: (String) => Any) {
                scala.concurrent.ops.spawn { while(true) { callback(key.toUpperCase) ; Thread.sleep(1000) } }
            }
        }

        object connection2 extends Functionality with PubSub with DB_Layer {
            def subscribe(key: String, callback: (String) => Any) {
                scala.concurrent.ops.spawn { while(true) { callback(key.toLowerCase) ; Thread.sleep(1000) } }
            }
        }
    }    
    repository.connection1.doSomething()
    repository.connection2.doSomething()
}

so now I have two layers. How do I get three? I feel like I'm losing the plot.

Answer 1

A comment isn't large enough to explain it, so here is an answer that basically says, "Don't do that!" and suggests an alternative.

The key problem you're running into is that you want to have multiple copies of some functionality, but you don't have any way to refer to it by name (only by type). The solution is: give it a name.

Let's take your double-cake pattern.

trait Foo { def foo(s: String): String }
trait Bar { def bar(s: String, f: String => Any): Any }
trait Bippy { this: Foo with Bar =>
  def bip(s: String) = bar(foo(s),println)
}

Okay, great, we can mix in Bippy to anything that implements Foo with Bar and we'll be able to bip. But what if Foo and Bar are implemented at different levels? If we instead

trait Bippy {
  def myFoo: Foo
  def myBar: Bar
  def bip(s: String) = myBar.bar(myFoo.foo(s), println)
}

this initially looks more awkward. (It is.) But it now lets you mix and match instead of being forced to cake in increasingly awkward ways. For example:

object Foozle extends Foo { theFoo =>
  def foo(s: String) = s.toUpperCase
  trait BippyImpl extends Bippy { this: Bar =>
    def myFoo = theFoo
    def myBar = this
  }
  object Woozle1 extends BippyImpl with Bar {
    def bar(s: String, f: String => Any) = f(s)
  }
  object Woozle2 extends BippyImpl with Bar {
    def bar(s: String, f: String => Any) = f(s.reverse)
  }
}

Now you can mix and match any functionality from anywhere; the only downside is you have to name it. (Here we've created a nested trait BippyImpl in order to split out the common parts for the Woozles, but we could just do it directly.)

Also, you don't get the original method names mixed in; you'll have to write proxies or refer to a member variable.

It misses out on some of the nice aspects of the cake pattern, but in my experience it ends up being a lot clearer than a massive mess of cake layers. And now you can see that you can nest it as deeply as you like and fill in the details you want wherever you need to.