web-dev-qa-db-ja.com

Scalaコンパイラが、シールされていないクラス/特性に対してパターンマッチング警告を出せないのはなぜですか?

n sealed traitまたはabstract class in Scalaを使用してからパターンマッチングを使用する場合、コンパイラは知らないのでしょうか。この特定のパターンマッチのコンパイル時に、このトレイト/クラスの可能な実装は何ですか?だから、もしそうなら、trait/abstract classがシールされていなくても、パターンマッチ警告を出せませんでした彼はすべての可能な依存関係/インポートをチェックすることで、どのタイプを使用できるかを知っているからですか?

例えば。 Option[A]があり、Some[A]に対してのみパターンマッチングを実行し、Noneに対してはパターンマッチングを実行しない場合、Optionがシールされているため、コンパイラーは文句を言います。

コンパイラがそれを認識/解決できない場合、なぜ彼はそれができないのですか?そして、コンパイラーが(理論的に)それを実行できる場合、それがScalaで使用されない理由は何ですか?そのような動作をサポートする他の言語はありますか?

10
valenterry

それは行うことができます(少なくともコンパイル時に既知のすべてのクラスに対して)、それはただ高価です。他のファイルが変更されるたびに、パターンマッチを含むすべてを効果的に再コンパイルする必要があるため、インクリメンタルコンパイルを完全に破棄します。

そして、あなたは何を買っていますか?新しい派生クラスが追加されたときに頻繁に変更する必要があるパターンマッチを記述するのはコードの匂いです。 オープン/クローズの原則 の違反です。継承を適切に使用すれば、そのようなパターンマッチを記述する必要はありません。そして、はい、オープン/クローズの原則は、クラスベースの継承のない関数型言語にも適用されます。実際、型クラス、マルチメソッド、単純な高階関数などの機能の間で、関数型言語を使用すると、変更を加えなくても拡張がはるかに簡単になります。

3
Karl Bielefeldt