8

リフレクションとコンパイラに関する Martin の基調講演を見た後、このクレイジーな質問が頭から離れないようです。マーティンは、特質が中心的な役割を果たす「(ウェディング) ケーキ パターン」について、とりわけ語っています。疑問に思っているのは、すでに特性を持っているのに、なぜパッケージが必要なのですか? packageできること、trait(少なくとも理論的には) できないことはありますか?

現在の実装について話しているのではなく、パッケージを特性に置き換えた場合のプログラミングがどのようになるかを想像しようとしているだけです。私の頭では、次のようになります。

  • キーワードが 1 つ少ない (packageは不要)
  • 必要package objectない

私のすべての質問を要約するには：

  1. 言語からパッケージを削除し、代わりに特性を使用することは理論的に可能ですか?
  2. この変更により、他にどのようなメリットが得られますか? （私はファーストクラスのパッケージとファーストクラスのインポートについて考えていましたが、スーパーコールは動的にバインドされていますが、ミックスインの構成はコンパイル時のものです）
  3. Java/JVM の互換性だけが邪魔になるのでしょうか?

アップデート

Daniel Spiewak は、この基調講演で、依存性注入は Cake パターンで実行できるすべてのことの氷山の一角にすぎないと語っています。

4

2 に答える 2

7

Martin Odersky は、Scala はトレイト、オブジェクト、メソッド、およびパスだけでうまくいくと言っています (何かを忘れていないことを願っています)。

クラスとパッケージの両方が存在するのは、Scala がホスト言語、つまりホスト プラットフォーム上で実行され (これは実際には興味深い点ではありません)、ホスト プラットフォームと相互運用される(これが重要な点です) ことを意図しているからです。Scala が相互運用することを意図しているホスト プラットフォームには、Java プラットフォームと CLI があります。どちらも、クラスとパッケージ (CLI の場合は名前空間) の概念を持っています。特性またはオブジェクト。これは、純粋に抽象的な特性との間で自明にマッピングできるインターフェースとは異なります。

上記のステートメントは、Scala からジェネリックを削除する可能性についての議論で作成されました。ジェネリックでできることはすべて、抽象型によっても実現できるからです。

于 2012-07-28T23:41:11.243 に答える
6

Scalaでは、オブジェクトとパッケージはほぼ同じ目的を果たし、オブジェクトはモジュールとも呼ばれます。オブジェクトには、もちろん他のオブジェクトや、重要なタイプを含む任意の定義を含めることができるため、オブジェクトはモジュールと見なす価値があります。

特性は、抽象的なモジュールと考えることができます。これには任意の定義を含めることができ、任意のメンバーを抽象化することができます。これもまた、タイプメンバーを含みます。対称性を強調するためだけに、これらすべてを暗唱しています。おそらくOTですが、私にとって、特性は、オブジェクトと機能のアイデアのマージと同じくらい、scalaの革新であるように思われます。

最終的に答えを与えるために：

  1. パッケージは（特性ではなく）オブジェクトを優先して削除できると思います。
  2. 利点は単純化です。パッケージオブジェクトを明示的に定義する必要はありません。
  3. パッケージは、Java/JVMとの互換性のためにオブジェクトとは異なると思います。

いくつかのより多くの解説：ビデオでは、マーティンは具体的なモジュールよりも特性（抽象的なモジュール）について話します。後者は、抽象的なモジュールのいくつかの組み合わせを組み立てて具体化するために最後の瞬間にのみ表示されるためです。

「ケーキを混ぜる」のでない場合でも、抽象モジュールを使用するのは良いことです。たとえば、コードをスケッチするときに、定義を含むモジュールを定義する場合があります。ただし、入力する準備ができていないタイプまたは値に到達したらすぐに、nullなどのダミーを指定しないでください。代わりに、オブジェクトをトレイトに切り替えて、メンバーを抽象化したままにします。

于 2012-07-28T11:48:10.797 に答える