問題タブ [case-class]

何か他のものを探しているときに、単なる偶然から、ケースクラスの継承がいかに悪魔的であるかについてのコメントをいくつか見つけました。、惨めな人と王様、エルフと魔法使いと呼ばれるものがありProductN、ケースクラスの継承により、ある種の非常に望ましいプロパティがどのように失われるかがありました。では、ケース クラスの継承の何が問題になっているのでしょうか。

パターンマッチングを使用できるケースクラスとしてRESTAPIからの応答をモデル化しようとしています。

継承を想定した場合に適していると思いましたが、これは非推奨であることがわかります。ケースクラスと継承に関連する質問がすでにあることは知っていますが、私の質問は、継承なしで次の「正しい方法」をどのようにモデル化するかについてです。

私は次の2つのケースクラスから始めました。これらは正常に機能します。

つまり、REST呼び出しは次のようなもので返されます。

次のようにパターンマッチできます。

正常に動作するなど。

問題が発生したのは次のとおりです。次のような、これらのケースクラスのヘルパー拡張機能が必要です。

これにより、次のような単純化されたパターン一致を実行できます。

また、RESTコードが直接使用して返すこともできます。

これは、動的に応答を作成する方が簡単です。

それで...

私はそれを（非推奨の警告とともに）コンパイルすることができます：

ただし、これはパターンマッチングでは機能しないようです。

これがどのように機能するかについてのアイデアはありますか？私はさまざまなアプローチを受け入れていますが、これはケースクラスの実用的な使用法を見つけるための私の試みでした

既存のメソッドの名前Extを変更すると同時に新しいメソッドを定義するという名前のトレイトを定義したいと思います。トレイトは、ケースクラスを拡張するために使用されます。私の現在の解決策はどういうわけかハッキーに見えます：equalsequalsByAttributesequals

このメソッドの再実装を回避できるように、Aのequalsメソッドを直接参照する方法があるのだろうか？equalsByAttributes

2012年7月12日編集

スーパー実装を参照するためのソリューションがあるので、トレイトによって拡張される基本クラス/トレイトの特定の実装にアクセスするsuper.METHOD_NAMEなど、同様の構文が必要だと思いました。これにより、私のトレイトは次のようになります。overridden.METHOD_NAMEExt

Option 型はサポートされているようですが、カスタム ケース クラスはどうでしょうか。

私はこれをやりたいと思っています：

ノード構造に再帰的なトラバージョンを実装しようとしています。

toStringのような要素を呼び出すAtom("test").toStringと、スタックオーバーフローが発生します。

foreachを明示的に呼び出していないことに注意してください。では、なぜスタックオーバーフローが発生するのですか？

この特定の問題を追加のクラスとからへTraversableNodeの暗黙の変換で解決しましたが、スタックオーバーフローの原因を知りたいと思います。ありがとう。NodeTraversableNode

名前付きパラメーターを使用してケースクラスを作成することは可能ですか? コンストラクターで名前付きパラメーターを使用してケースクラスオブジェクトを構築することを意味します。

私のケースクラスには多くのフィールドがあります。多くの名前のないパラメーターを持つコンストラクターを使用すると、エラーが発生しやすくなります。

私は取得したいと思います(現時点では動作しない例です):

回避策として、以下の抜粋に示すようなファクトリ メソッドを提供できますが、これは醜い解決策です。

手がかりはありますか？:)

編集: これは intellij idea scala プラグインの一部の古いバージョンのバグでした。もう反対票を投じないでください;）

Squerylをベースにしたアプリケーションがあります。モデルをケースクラスとして定義します。これは主に、コピーメソッドがあると便利だからです。

厳密に関連する2つのモデルがあります。フィールドは同じであり、多くの操作が共通しており、同じDBテーブルに格納されます。ただし、2つのケースのいずれかでのみ意味がある、または両方のケースで意味があるが異なる動作がいくつかあります。

これまで、モデルのタイプを区別するフラグを持つ単一のケースクラスのみを使用してきました。モデルのタイプに基づいて異なるすべてのメソッドは、ifで始まります。これは煩わしく、タイプセーフではありません。

私がやりたいのは、祖先のケースクラスの一般的な動作とフィールドを因数分解し、2つの実際のモデルにそれを継承させることです。しかし、私が理解している限り、Scalaではケースクラスからの継承は嫌われており、サブクラス自体がケースクラス（私の場合ではない）である場合でも禁止されています。

ケースクラスから継承する際に注意すべき問題と落とし穴は何ですか？私の場合、そうすることは理にかなっていますか？

次のようなケースクラスがあります。

一致させたい：

その3つのケースを1つのケースにマージする方法はありますか（中間の親クラスをA、B、Cに追加することなく）？A、B、C、またはExpの定義を変更できません。ある種の：

これは明らかに機能せず、どちらも機能しません。

scala の相互再帰型と同様に、Scala で相互再帰型を作成しようとしています。

このタイプで定義されたグラフを作成しようとしています（コンパイルします）：

しかし、このタイプで実際に何かを作成する方法がわかりません。ノード A をエッジ B と C で初期化するには、少なくとも B と C への遅延参照が必要ですが、同時に作成することはできません。それらのエッジセット。

この再帰型を実装することは可能ですか?

編集：

これは、明示的な隣接リストを自己参照リストに変換するために現在使用しているソリューションです。

または代わりに、エッジリストから

みんなアドバイスありがとう！

ケース クラスを定義するとき、デフォルトのコンパニオン オブジェクトにはcurried、ケース クラス コンストラクターのカリー化されたバージョンを取得するための優れたメソッドがあります。

ただし、明示的なコンパニオン オブジェクトを定義するとすぐに、このメソッドは表示されなくなります。

次のように戻すことができます：

ただし、明示的なコンパニオンを定義すると消える理由を知りたいです (たとえば、 とは対照的にapply)?

(スカラ 2.9.2)