强制执行特质以提供该特质可以扩展的内部类

Question

Is it possible for a trait to impose a requirement that its implementing classes implement some inner class, which it can then extend? Eg

trait BaseTrait {
  // not actually an "abstract class", but a requirement that
  // subclasses provide a class named Foo with this constructor signature
  abstract class Foo(bar: Bar)

  def normalFoo(bar: Bar): Foo = new Foo(bar)

  // trait needs to be able to extend the Foo class implemented by the subclass.
  // this seems to be the impossible part, as far as I can tell...
  def fancyFoo(bar: Bar): Foo with SomeMixin = new Foo(bar) with SomeMixin {
    def anExtraMethod() = println("I'm an extra!")
  }
}

object ThingA extends BaseTrait {
  class Foo(bar: Bar) {
    def getThingAStuff() = println("I'm part of ThingA")
  }
}
object ThingB extends BaseTrait {
  class Foo(bar: Bar) {
    def getThingBStuff() = println("I'm part of ThingB")
  }
}

// calling `fancyFoo` on the concrete implementations should grant
// access to the specific methods in their respective `Foo` classes,
// as well as the "extra method" that the trait adds
val aFoo: ThingA.Foo with SomeMixin = ThingA.fancyFoo(bar)
aFoo.getThingAStuff()
aFoo.anExtraMethod()

val bFoo: ThingB.Foo with SomeMixin = ThingB.fancyFoo(bar)
bFoo.getThingBStuff()
bFoo.anExtraMethod()

The reason I want this is that I've got a large number of ThingX classes which all are currently forced to implement their own equivalent of fancyFoo (and other similar methods that require a Mixin to be added to their specific Foo class). I want to cut down on the boilerplate by moving fancyFoo and its friends into the BaseTrait, but I've been unable to come up with anything less-verbose than what's already there.

---

edit:

My generalization above may have obscured the overall intent, so here's some background:

My actual use case revolves around modelling a database schema and some table join logic. The team started moving away from Slick's "lifted" syntax and more towards raw sql, and this system popped up to help support writing raw queries.

Foo = TableReference . Each of the ThingX objects represent a particular table, and their respective reference classes contain methods to reference that table's columns.

SomeMixin = TableJoin , which was supposed to add join logic (ie how to reach one table from another table). The ThingX objects typically define a def direct to get a direct reference to the table (ie the start of a the FROM clause in a SQL query), a def from(someOtherRef) that creates an INNER JOIN , and a def optFrom(someOtherRef) that creates a LEFT JOIN . Those three methods are what I was trying to abstract away into the BaseTrait .

I believe we do need to be able to provide a plain TableReference as well as provide a TableReference with TableJoin , as we have a utility for combining all of the join logic and we want to forbid references without any join logic from being passed into it. There are several usages of plain references throughout the codebase.

I'm hoping to define something along the lines of

trait TableSupport {
  type Reference <: TableReference
  trait CanMatch[Ref] {
    // corresponds to the `ON` part of a `JOIN` clause
    def matchCondition(self: Reference, other: Ref): RawSQL
  }
  def defaultAlias: String

  // All of the below would be implemented by the `TableSupport` trait
  // in terms of the `Reference` constructor and mixing in TableJoin.
  // But currently each table companion has to explicitly implement these.

  def reference(alias: String = defaultAlias): Reference = ???
  def direct(alias: String = defaultAlias): Reference with TableJoin = ???
  def from[Ref: CanMatch](ref: Ref, alias: String = defaultAlias): Reference with TableJoin = ???
  def optFrom[Ref: CanMatch](ref: Ref, alias: String = defaultAlias): Reference with TableJoin = ???
}

I get stuck on the last four methods above, since it seems they require the seemingly-nonexistent feature I ask for in my original question, or for the TableSupport implementors to explicitly define the separate methods to create a Reference and a Reference with TableJoin , which ends up defeating the purpose of reducing boilerplate, because of the additional boilerplate of implementing those methods.

Answer 1

The solution I found was to wrap the classes rather than extend them, and to use an implicit unwrapper to let me interact with things the same was as if they had been extended.

SomeTableRef with TableJoin becomes TableJoin[SomeTableRef] ie

class TableJoin[T <: TableReference](val self: T, val joinStep: RawSQL)
object TableJoin {
  import language.implicitConversions
  implicit def unwrap[T <: TableReference](tj: TableJoin[T]): T = tj.self
}

Since the compiler is able to find the unwrap method for a TableJoin[T] without any imports, I can treat it the same as if it were a mixin:

class SomeTableRef(alias: String) extends TableReference {
  def id = column("ID")
}
val joinedRef = new TableJoin(new SomeTableRef(defaultAlias), /* raw sql */)
joinedRef.id // compiles fine because of `unwrap`

Using this approach, I was able to implement the direct , from and optFrom methods as I had hoped.