스칼라 컴파일러가 봉인되지 않은 클래스 / 특성에 대해 패턴 일치 경고를 표시 할 수없는 이유는 무엇입니까?

내가 사용하는 경우 취소 밀봉 trait또는 abstract class스칼라 후 사용 패턴 매칭을 궁금해 사용할 수 있습니다이 특성 / 클래스의 수 어떻게 구현이 특정 patternmatch에 대한 컴파일시에 컴파일러 알고하지 않는 이유는 무엇입니까? 따라서 그렇다면 가능한 모든 종속성 / 가져 오기를 확인하여 사용할 수 있는 유형을 알고 있기 때문에 trait/ abstract class가 봉인되어 있지 않아도 패턴 일치 경고를 표시 할 수 없습니까?

예를 들어 Option[A]및에 대해서만 패턴 일치를하고 패턴이 일치 Some[A]하지 않으면 None컴파일러 Option가 봉인 되기 때문에 불평 합니다.

컴파일러가 그것을 알 수 없거나 해결할 수 없다면 왜 할 수 없습니까? 컴파일러가 이론적으로 그렇게 할 수 있다면 스칼라에서 사용되지 않는 이유는 무엇입니까? 이런 종류의 행동을 지원하는 다른 언어가 있습니까?

클래스의 모든 하위 클래스를 파악하는 것을 클래스 계층 분석이라고하며 동적 코드로드가있는 언어에서 정적 CHA를 수행하는 것은 중지 문제를 해결하는 것과 같습니다.

또한 Scala의 목표 중 하나는 독립적 인 모듈의 개별 컴파일 및 배포입니다. 따라서 컴파일러는 클래스가 다른 모듈에서 서브 클래 싱되는지 여부를 알 수 없습니다. 하나 이상의 모듈을 보지 않기 때문입니다. (결국 시스템에 해당 모듈이없는 다른 모듈의 인터페이스에 대해 모듈을 컴파일 할 수 있습니다!) 따라서 sealed모든 서브 클래스를 동일한 컴파일 단위로 정의해야합니다.

이것이 JVM이 C ++ 컴파일러와 경쟁하기 쉬운 이유 중 하나입니다. C ++ 컴파일러는 일반적으로 정적 컴파일러이므로 일반적으로 메소드가 재정의되는지 여부를 알 수 없으므로 인라인 할 수 없습니다. JVM OTOH는 일반적으로 동적 컴파일러이며 메소드가 재정의되었는지 여부를 파악하기 위해 CHA를 수행 할 필요가 없으며 런타임시 클래스 계층을 볼 수 있습니다. 그리고 나중에 프로그램 실행의 새로운 시점에 새로운 하위 클래스가 나오더라도 그다지 중요하지 않고 인라인없이 해당 코드 조각을 다시 컴파일하십시오.

참고 :이 모든 것은 스칼라 내에서만 적용됩니다. JVM에는 개념이 없으므로 다른 언어와 통신 할 수있는 방법이 없으므로 다른 JVM 언어 에서 클래스 sealed를 서브 클래 싱하는 것이 가능합니다 . 속성에 기록 주석 있지만, 다른 언어 '컴파일러는 분명히 계정으로 그 주석을하지 않습니다.sealedsealedScalaSig

수 (적어도 컴파일 타임에 알려진 모든 클래스), 그냥 비싼 할 수. 패턴 일치가 포함 된 모든 항목은 다른 파일이 변경 될 때마다 효과적으로 재 컴파일해야하므로 증분 컴파일을 완전히 중단해야합니다.

그리고 당신은 무엇을 사고 있습니까? 새로운 파생 클래스가 추가 될 때 자주 변경해야하는 패턴 일치를 작성하는 것은 코드 냄새입니다. 그것은 개방 / 폐쇄 원칙을 위반하는 것 입니다. 상속을 올바르게 사용하면 이런 종류의 패턴 일치를 작성할 필요가 없습니다. 그리고 개방 / 폐쇄 원칙은 클래스 기반 상속이없는 기능적 언어에도 적용됩니다. 실제로 타입 클래스, 멀티 메소드, 단순한 고차 함수와 같은 기능 사이에서 기능적 언어는 수정없이 확장을 훨씬 쉽게 해줍니다.