問題タブ [case-class]

反射フィールドの値で設定するScalaアプリを作成しています。これは問題なく動作します。

ただし、フィールド値を設定するには、インスタンスを作成する必要があります。空のコンストラクターを持つクラスがある場合、classOf [Person].getConstructors...を使用してこれを簡単に行うことができます。

ただし、空でないコンストラクターを使用してCaseクラスでこれを実行しようとすると、機能しません。すべてのフィールド名とその値、および作成する必要のあるオブジェクトタイプがあります。自分が持っているものを使って、Case Classをなんとかしてインスタンス化できますか？

私が持っていないのは、Case Classコンストラクターからのパラメーター名、またはパラメーターなしでこれを作成し、リフレクションを介して値を設定する方法だけです。

例に行きましょう。

私は以下を持っています

これはScalaコンストラクターのオーバーロードに対するフォローアップの質問ですか？コンストラクターをオーバーロードするのではなく、制限された形式の入力で動作し、オーバーライドするケースクラスコンストラクターが必要です。

これはコンパイルされません。私はこれを数回繰り返してみましたが、それらはすべてコンパイラに戻ってきて、「this」を期待していると言っていますが、代わりに「if」が見つかりました。どうすれば私が望む振る舞いを得ることができますか？

scala で playframework を実行すると、非常に奇妙な動作が発生します。データベース アクセス レイヤーとして anorm を使用したため、いくつかのコードを実行し始めたところ、非常に奇妙な scala コンパイラの動作が見られました。

これは動作しているコードです:

と：

今のところコンパイルエラーはありません。正常に動作します。しかし、プロパティ名を変更するとエラーが発生しました:

私は Scala にまったく慣れていないので_、魔法のキーワードまたはその他の魔法のものだと思いました。

そのため、プロパティ名を に変更しましaBB_AccAdたが、コンパイル エラーは発生しませんでした。

おっと...

次の面白いこと: これを に名前を変更したところAAbbdddsadasdasAAFFFFeeee、再びコンパイル エラーが発生しました。では、Scala がリテラルのセットに対してコンパイル エラーをスローする動機は何でしょう?

これはバグですか、それとも機能ですか? :-)

次のようなケースクラスがある場合:

そして、次のような 2 つのインスタンスがあります。

結果が次のようになるように、フィールド z を除いて、インスタンス 1 をインスタンス 2 にマージすることは可能ですか?

私のユースケースは、Scala API を介してバックボーン アプリに JSON オブジェクトを渡すことです。バックボーン アプリは、保存/更新できるように同じ構造の JSON を返します。これらの JSON オブジェクトは、簡単に Scala を操作できるようにケース クラスとして解析されます。ただし、一部のフィールドはクライアント側で更新しないでください (creationDate など)。今のところ、私は手動でマージを行っていますが、強化されたコピー機能のような、より一般的なソリューションが必要です。

私が欲しいのは次のようなものです：

しかし、私はそれがタイプセーフであることを望みます:)

編集: 私のケースクラスにはさらに多くのフィールドがあり、明示的にマージしないように言わない限り、デフォルトの動作でフィールドをマージしたいと思います。

Scalaケースクラスからマップへの（逆）シリアル化を実装しようとしています（field_name-> field_value）。問題は、関数を作成する方法がわからないことです。関数は、ケースクラスタイプとマップを取り、インスタンス化して、データを入力して返します。これがいくつかのJSONライブラリで行われているのを見てきましたが、コードを取得できません。

私は自分のコードでcaseクラスを多用し、caseクラスの基礎となる等価定義に応答して正しく動作しました。次に、ケースクラスに別のフィールドメンバーを追加する必要があることがわかりました。

1. したがってvar、caseクラスにフィールドメンバーを追加すると、caseクラスの等価属性が台無しになりますか？
2. 1がyesの場合、varフィールド値を1回変更しただけで、その後、ケースクラスがコレクションに入る前、または同等性の比較を行う前に、再割り当てが行われない場合はどうなりますか？それでも同等性の動作が台無しになりますか？

カスタム例外タイプはcase classes にする必要がありますか?

プラス面として、抽出器があります。

マイナス面としては、等価セマンティクスが正しくありません。しかし、オーバーライドすることでそれを回避できますequals。

case classでは、概念レベルでそれらをesにすることは理にかなっていますか?

2つのプロパティを定義する抽象クラスを考えてみましょう

これは、次のようなさまざまなケースクラスの基本クラスです。

目標：最終的に、前述のケースクラスのインスタンスを2つの方法で作成できるようにしたいと思います。

アプローチ：したがって、 shasを部分的に構築できるようにするヘルパークラスを定義することは合理的と思われます。A

問題：現在の機械では、のような呼び出しは許可されていませんBar(1)。これは、実際には、の呼び出しBar.apply(1)、つまりapply、コンパイラによって生成されたオブジェクトによって定義されたメソッドの呼び出しであるためBarです。

Barコンパイラにオブジェクトをとして生成させることができれば素晴らしいと思いますobject Bar extends PartialAConstructor。

ただし、ケースクラスのコンパニオンオブジェクトの生成に影響を与えることはできないようです。

必要なプロパティ：

• ケースクラス：などは、構造的同等性などのコンパイラで生成された機能と、自動生成されたエクストラクタを使用したいので、ケースクラスのままにする必要がFooあります。Barcopy

• 「完全な」構造的同等性：ケースクラスを次のように定義する

  コンパイラによって生成されたメソッドは引数の最初のリストのみを考慮するため、オプションではありません。equalsしたがって、次のことが誤って成立します。

  /li>

• コードの繰り返しをできるだけ少なくする：たとえば、もちろん、

  Aしかし、それは、Foo拡張するすべてのケースクラスに対して実行する必要がありますBar。

与えられた:

魔法のように作成するものが欲しい:

そのようなものは存在しますか（任意のサイズのもの）？

私はJavaのバックグラウンドを持つscalaが初めてです。

ケースクラスとして葉を持ち、ノード抽象クラスまたは特性を持つクラス継承ツリーでスーパークラス(または特性)をパターンマッチする方法はありますか? 私の知る限り、ケース クラスの継承は許可されていません。

大きな継承ツリーの抽象クラスのパターンマッチングは非常に役立つと思います

次のコードでは、コンパイル中の match ステートメント エラーの最後のケース