클래스, 연관된 패밀리 -> 컨테이너, 키 및 요소 : 누가 누구입니까? 를 수집의 인스턴스는 관련 유형 (동의어) Elem 모델의 CE가 -에 대한 <a href="http://www.haskell.org/haskellwiki/GHC/Indexed_types" rel="nofollow">type families on haskellwiki</a> 읽기

Question

, 나는 내가 (아마도 역효과) OOP의 은유를 사용할 때 이것은 나에게 의미가 예를

class Collects ce where 
    type Elem ce 
    empty :: ce 
    insert :: Elem ce -> ce -> ce 

를 참조하십시오. 컬렉션은 요소보다 어떻게 든 더 크다.

관련 데이터 제품군에 대한 예가 해당 모델에 맞지 않기 때문에 혼란 스럽습니다.

class GMapKey k where 
    data GMap k :: * -> * 
    empty  :: Gmap k v 
    insert  :: k -> v -> GMap k v -> Gmap k v 

지도는 대 수집하고 대와 KS보다 '더 큰'느낀다. GMapKey와 연관된 GMap이있는 것처럼 보입니다. 관계가 다른 방향으로 갈 것으로 예상됩니다.

데이터 패밀리와 유형 동의어 패밀리 중 하나를 선택할 때 따라야 할 패턴입니까 (데이터 패밀리 : 컨테이너가 연관된 유형, 동의어 계열 유형 : 요소가 연관된 유형)? 또는 IS A/HAS A 구분이 부적절하며 두 예제가 서로 바뀔 수 있습니까? GMap 가족 k와 연결되어, 당신은 GMapKey로 사용 k에 대한 k과 관련된 GMap 형 가족 인스턴스가 있어야합니다

Answer 1

나는 그것의 생각이 방법을 건의 할 것입니다.

이러한 옵션 중 하나를 선택하는 것은 무엇보다 필요에 따라 다릅니다. 키 유형이지도 구현을 지시 할 때 GMap k 접근 방식이 바람직합니다. Int 키에는 IntMap을 사용하고 다른 키에는 Map의 다른 유형을 사용하십시오.

Answer 2

IS A/HAS A 관계는 나쁜 은유입니다. 더 나은 직관은 "함께"또는 "전문 (일부 유형)"것입니다. 실제로 당신이 유형을 해결하는 경우

f :: GMapKey k => k -> GMap k v -> v 

모두 제 1 및 제 2 매개 변수 다형성하지만 함께을 통합해야한다는 것을 의미합니다. 하나가 다른 하나 안에 포함될 필요는 없습니다.

---

는 일이 일반화 방법에 대해 생각해야 사용할 "방향"을 결정합니다. "키"에 관련된 유형 인 "컨테이너"클래스를 정의하면 각 컨테이너 유형이 단일 키에서 "이 클래스 인터페이스를 인스턴스화합니다"라고 말합니다. 각 "컨테이너"에는 하나의 연관된 "키"가 있지만 "키"는 많은 컨테이너에 대한 연관 유형이 될 수 있으므로 다 대일 관계입니다. 다른 방향으로 가면 각 "키"가 특정 종류의 "컨테이너"로 제한되지만 컨테이너에는 인덱스 할 수있는 많은 다른 키가있을 수 있습니다.