2011-04-07 4 views
2

this.types (단독 유형)로 여전히 어려움을 겪고 있습니다. 이 시나리오를 가정 :반환 유형이 해당 메소드의 인수의 단독 유형 인 메소드 정의

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 
} 

다음은 실패 분명히 rRef[a.type, Int] 유형 Ref[Access, Int]이며하지

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

때문이다. 내 생각 엔 문제가 내가

"불법 의존 방법 유형"에 관해서 인해 컴파일되지
def single[A <: Access, V](v: V)(implicit a: A): Ref[a.type, V] = ... 

같은 라인 ...

나는이 문제를 해결할 수있는 방법 어떤 아이디어가 필요 것입니다. 요구 사항은 유형에 통화에 명시 적으로 주석을 달지 않아야한다는 것입니다. 즉, 내가 할 이해하기 쉬운 이유로 Ref.single[a.type, Int](44)(a) 쓸 싶지 않아요. "참고로, 그리고 질문을 닫습니다"대답 할 스레드 Constraining an operation by matching a type parameter to an argument's path-dependent type에 참조 해명으로 편집


는 - 제가 추가하고 싶은 것은 객체를 만들 수있는 가능성 (참고) 액세스의 공장 방법 을 사용하는 것이 아니라 외부 (예 : new 문 사용). Access의 정의에 따라 시스템을 제한 할 수 없기 때문에 추가 객체로 시스템을 확장 할 수 있어야합니다.

+0

다른 질문이 추가되었습니다. http://stackoverflow.com/questions/5575030/driving-a-singleton-type -through-a-brickwall - 내가 그걸 해결할 수 있다면, 이것도 결과로 해결 될거야 (희망) –

답변

1

몇 가지 가능성이 있습니다. 스칼라 2.8/2.8.1을 사용하면 개인 옵션 -Ydependent-method-types 다음

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

잘 컴파일과 솔루션을 사용할 수 있습니다. 당신이 개인 옵션이기 때문에 의존하는 방법의 유형을 피하려면

, 당신은 여전히 ​​당신의 첫번째 제안은 명시 적으로 Ref.single에 전화를 입력하여 컴파일 할 수 있습니다 :

당신은 그래도 유형을 지정해야
val r = Ref.single[a.type, Int](44) 

, 싱글 톤 유형은 절대로 추론되지 않습니다. 문제는 싱글 톤 유형이 유추되지 않는 문제와 같지만 관련이 없습니다. How to correctly type-annotate this HList?

+0

대단히 고마워. 처음에는 dependent-method-types 옵션을 들었습니다. 그래서 타입 시스템은 그것을 처리 할 수 ​​있습니다. 나는 이것이 앞으로 스칼라 버전에서 활성화되거나 공개 될지 궁금하다. –

관련 문제