Scala は素晴らしい言語ですが、独自のランタイムがあればどのように改善できるのでしょうか?
つまり、JVM の選択により、どのような設計上の選択が行われたのでしょうか?
1564 次
3 に答える
26
私が知っている最も重要な妥協点は次の 2 つです。
- 型の消去(「型に反映」): Java コンパイルを回避するためにマニフェストを管理する必要があります (下位互換性の理由から、JVM とは無関係です)。
- プリミティブ型のコレクション: 例:配列
Scala 2.8 で配列を処理する新しいスキーム。ボックス化/ボックス化解除やその他のコンパイラ マジックの代わりに、スキームは暗黙的な変換とマニフェストに依存して配列を統合します。
ジェネリック型 (境界あり) を管理する場合の JVM の主な制限は次の 2 つです。
ただし、次のことも検討できます。
- テールコールの最適化はまだ JVM によって完全にサポートされておらず、とにかく実行するのが困難でした(それでも、Scala 2.8 ではアノテーションが導入されて
@tailrecいます) 。 - UAP (ユニバーサル アクセス プリンシパル)をエミュレートする必要があり (Java ではサポートされていません)、すぐにバリュー ホルダー用に完成します (
@proxy) - すべてのミックスインメカニズムもエミュレートする必要があります
- より一般的に言えば、Scala によって導入された膨大な数の静的型は (ほとんどの場合) Java で生成する必要があります。
可能な限り多くの可能性をカバーするために、Scala は以下を提供します。
- 従来のクラスタイプ、
- 値クラスの種類、
- null 非許容型、
- モナド型、
- 特性タイプ、
- シングルトン オブジェクト タイプ (手続き型モジュール、ユーティリティ クラスなど)、
- 複合型、
- 機能タイプ、
- ケースクラス、
- パス依存型、
- 匿名型、
- 自己型、
- タイプエイリアス、
- ジェネリック型、
- 共変のジェネリック型、
- 反変のジェネリック型、
- 限定されたジェネリック型、
- 抽象型、
- 実在型、
- 暗黙の型、
- 拡張型、
- 制限された型を表示し、
- 他のすべてが失敗したときにダックタイピングの形式を可能にする構造型
于 2010-04-21T12:48:16.140 に答える
20
この記事は、Martin Odersky (Scala の作成者) とのディスカッションであり、Java との互換性のために Scala で行われた妥協点が含まれています。記事では次のように述べています。
- メソッドの静的オーバーロード
- 特性とクラスの両方を持つ
nullポインターの組み込み。
于 2010-04-21T18:33:41.720 に答える
3
文化的な後遺症よりもランタイムの問題が少ない: 普遍的な平等、ハッシュ、toString。
VM とのより深い結びつき: デフォルトでの厳密な評価、不純な関数、例外。
于 2010-04-23T16:33:22.383 に答える