問題タブ [case-class]

case classScalaインスタンスを変換できる良い方法はありますか?

ある種のマッピングに、例えば

これは、定義済みのものだけでなく、どのケースクラスでも機能します。基になる Product クラスに問い合わせるメソッドを作成することで、ケース クラス名を引き出すことができることがわかりました。

だから私は同様の解決策を探していますが、ケースクラスフィールド用です。ソリューションには Java リフレクションを使用する必要があるかもしれないと想像しますが、ケース クラスの基になる実装が変更された場合に、Scala の将来のリリースで壊れる可能性のあるものを書くのは嫌いです。

現在、私は Scala サーバーに取り組んでおり、ケース クラスを使用してプロトコルとそのすべてのメッセージと例外を定義しています。しかし、これらを Java マップに変換して、クライアント実装で使用できるようにメッセージング レイヤーを介して送信する必要があります。私の現在の実装では、各ケース クラスの翻訳を個別に定義しているだけですが、一般化された解決策を見つけられるとよいでしょう。

Scala アクターの例では、パラメーターなしのメッセージがアクター ( thisなど) に送信される場所を確認しましたcase class。es (またはcase objects) が作成され、メッセージとして使用されます。シンボルも同じように機能し、少しきれいに見えます。Erlang に関する本を読んだ後では、より自然に見えます。リモート アクターに対しては、シンボルの等価性が機能すると思います。

パラメーターを持つメッセージの場合、ケース クラスが当然の選択になるため、メッセージ タイプ間の一貫性が 1 つの問題になるのではないでしょうか?

いずれかのアプローチを採用する理由はありますか?

Scalaでケースクラス（またはケースオブジェクト）を使用する場合と列挙を拡張する場合のベストプラクティスのガイドラインはありますか？

それらは同じ利点のいくつかを提供するようです。

これがコンパイルに失敗する (または動作する) のはなぜですか?

コンパイラ エラーは次のとおりです。

これは期待どおりにコンパイルおよび実行されることに注意してください。

補遺

参考までに、これはコンパイルして正常に実行されます。

特定のデバッグ目的で、実行時にフィールドを検査できるように、ケース クラスに混在できる (Scala 2.8 の) トレイトを作成しようとしています。ソース ファイルで宣言された順序に戻して、ケース クラス内の他のフィールドを省略したいと考えています。例えば：

上記の実装は、Product 内のフィールドの位置とその名前の間の関係をそれらのフィールドの値の等価性によって推測するため、明らかに欠陥があります。

これを実装する方法はありますか？

パラメータリストのないケースクラスがScalaから非推奨になったのはなぜですか？そして、なぜコンパイラは()代わりにパラメータリストとして使用することを提案するのですか？

編集 ：

誰かが私の2番目の質問に答えてください...：|

case classaと aの違いを Google で検索しましたclass。クラスでパターンマッチングを行いたい場合は、ケースクラスを使用することを誰もが言及しています。それ以外の場合は、クラスを使用し、equals やハッシュ コードのオーバーライドなどの追加の特典についても言及します。しかし、これらがクラスの代わりにケース クラスを使用する唯一の理由でしょうか?

Scala のこの機能には、非常に重要な理由があるはずです。説明は何ですか、または Scala ケース クラスについてさらに学ぶためのリソースはありますか?

Scala 2.8 では、ケース クラスのコンストラクタをオーバーロードする方法はありますか?

はいの場合は、説明するためにスニペットを入れてください。そうでない場合は、その理由を説明してください。

次のようなケースオブジェクトの階層をScalaで作成しました。

アクセスしたいJavaコードもありますPressureSensorが、以下は機能しません。

PressureSensorでは、 Javaからcaseオブジェクトを参照するにはどうすればよいですか？PressureSensorとクラスの両方のバイトコードを逆コンパイルしPressureSensor$たところ、次のようになりました。

しかし、それは素晴らしい洞察をもたらしませんでした。