내 스칼라 응용 프로그램에서 implicits를 어떻게 구성해야합니까?

Question

몇 가지 스칼라 도구를 작성 했으므로 필자는 코드 최적화를위한 최선의 방법, 특히 함축적 인 내용을 파악하려고 노력하고 있습니다. 나는 2 가지 목표를 가지고있다 :

• 가끔, 나는 내가 원하는 암시를 가져올 수 있기를 원한다.
• 그 외, 나는 모든 것을 가져오고 싶습니다.

가 implicits 중복되지 않도록하려면 , 나는이 구조에 왔어요

(방법 scalaz 유사이 배치) :이 허용

case class StringW(s : String) { 
    def contrived = s + "?" 
} 

trait StringWImplicits { 
    implicit def To(s : String) = StringW(s) 
    implicit def From(sw : StringW) = sw.s 
} 

object StringW extends StringWImplicits 

// Elsewhere on Monkey Island 

object World extends StringWImplicits with ListWImplicits with MoreImplicits 

나에게 단지

import StringW._ // Selective import 

또는 (대부분의 경우)

import World._. // Import everything 

다른 사람들은 그렇게합니까?

Answer 1

내가 어디에서 왔는지 모를 경우 implicit 전환이 위험하다고 생각합니다. 내 경우, 나는 Conversions 수업 시간에 내 implicit들 넣고 import 그것은 내가 같은 다양한 trait의에서 implicits "상속"처럼 확실하지 않다 가능

def someMethod(d: Date) ; Unit { 
    import mydate.Conversions._ 
    val tz = TimeZone.getDefault 
    val timeOfDay = d.getTimeOfDay(tz) //implicit used here 
    ... 
} 

과 사용에 가까운 그 이유는 잘못된 Java 실습으로 interface을 구현했기 때문에 상수를 직접 사용할 수 있습니다 (정적 가져 오기가 대신 사용됨).

Answer 2

일반적으로 가져 오기 내용이 implicit 개임을 분명하게 알리는 객체에서 변환은 implicit입니다.

예를 들어 클래스가 com.foo.bar.FilthyRichString 인 경우 암시 적 변환은 com.foo.bar.implicit.FilthyRichStringImplicit이됩니다. 나는 이름이 길다는 것을 알고 있습니다. 그러나 이것이 우리가 IDE를 가지고있는 이유입니다. (그리고 Scala IDE 지원은 점점 좋아지고 있습니다.) 이 작업을 수행하는 방법은 모든 암시 적 변환을 10 second code review에서 명확하게 볼 수있는 것이 중요하다고 생각하는 것입니다. 다음 코드를 볼 수 있습니다 :

// other imports 
import com.foo.bar.FilthyRichString 

import com.foo.bar.util.Logger 
import com.foo.bar.util.FileIO 

import com.foo.bar.implicits.FilthyRichStringImplicit._ 
import com.foo.bar.implicits.MyListImplicit._ 
// other implicits 

이 소스 파일에서 활성화 된 모든 암시 적 변환을 한 눈에 볼 수 있습니다. 가져 오기가 패키지별로 그룹화되고 다른 패키지 사이에 새로운 라인이있는 규칙을 사용하면 패키지는 모두 함께 모이게됩니다.

동일한 인수의 행을 따라 모든 암시 적 변환을 보유하는 포괄적 인 객체가 마음에 들지 않습니다. 큰 프로젝트에서 모든 소스 파일에서 의 암시 적 변환을 실제로 사용 하시겠습니까? 나는 이것이 코드의 다른 부분들 사이의 매우 긴밀한 결합을 의미한다고 생각한다.

또한 catch-all 개체는 문서화에 적합하지 않습니다. 파일에 사용 된 모든 암시 적 변환을 명시 적으로 작성하는 경우 가져 오기 명령문을 살펴보고 암시 적 클래스의 문서로 바로 이동할 수 있습니다. catch-all 객체의 경우에는 큰 객체에서 거대한 객체를보아야하고 이후의 암시 적 변환을 검색해야합니다.

oxbow_lakes에 동의합니다. trait에 암시 적 변환이있는 것은 나쁜 습관인데, 그 이유는 상속의 유혹 때문입니다. 그 라인을 따라, 나는 암시 적 변환을 유지하는 객체를 유혹을 피하기 위해서 단지 final으로 만들 것이다. 암시 적 변환이 코드에서 사용되지 않는 한 가능한 한 사용에 가깝게 가져 오는 것이 좋습니다.

-- Flaviu Cipcigan