定义一个返回类型为该方法的参数的单例类型的方法

Question

Still struggling with this.types (singleton types). Assume this scenario:

trait Sys[A <: Access] {
  def in[T](v: String): AccessPrepare[A]
}

trait AccessPrepare[A <: Access] {
  val a: A
  def apply[T](fun: a.type => T): T
}

object Ref {
  def single[A <: Access, V](v: V)(implicit a: A): Ref[A, V] = ???
}
trait Ref[A, V]

trait Access {
  def set(r: Ref[this.type, Int]): Unit
}

The following fails:

def test(sys: Sys[Access]): Unit =
  sys.in("v1") { implicit a =>
    val r = Ref.single(44)
    a.set(r)
  }

because apparently r is of type Ref[Access, Int] and not Ref[a.type, Int] . My guess is the problem is that I would need a line like

def single[A <: Access, V](v: V)(implicit a: A): Ref[a.type, V] = ...

which isn't compiling as due to "illegal dependent method type"...

Any ideas how I can fix this. The demand is that I do not explicitly annotate calls with types. That is, I do not want to write Ref.single[a.type, Int](44)(a) for comprehensible reasons.

---

EDIT

As a clarification, with reference to answer "FYI, and to close the question" in thread Constraining an operation by matching a type parameter to an argument's path-dependent type -- what I would like to have in addition is the possibility to create objects (Refs) not by using a factory method in the Access but somewhere outside (eg with a new statement). Because the system cannot be limited by the definition of Access, I must be able to extend it with further objects.

Answer 1

You have several possibilities. With Scala 2.8/2.8.1, you can use the private option -Ydependent-method-types and then your solution with

def single[ A <: Access, V ]( v: V )( implicit a: A ) : Ref[ a.type, V ] = // ...

compiles fine.

If you want to avoid dependent method types because it's a private option, you can still make your first proposal compile by explicitly typing the call to Ref.single :

  val r = Ref.single[a.type, Int](44)

You need to specify the type, though, as singleton types are never inferred. You problem is not the same as, but related to, the problem that singleton types are not inferred: see How to correctly type-annotate this HList?