問題タブ [structural-typing]

Scala が以下を最適化できない理由:

を。

に：

b.

?

この場合、なぜ構造型付けを使用する必要があるのでしょうか? スタイルbでの記述はあまりにも醜いため (1. ロジックの局所性が失われ、2. これらの追加の明示的なクラスの名前を不必要に考案する必要があるため)、aははるかにパフォーマンスが低いため、 Scala コンパイラーにこの最適化を実行してもらいたいと思います。 bよりも。

Clojure1.2のプロトコルに関するRichHickeyのインタビューを見て、 Clojureについてほとんど知らなかった後、Clojureプロトコルについていくつか質問があります。

• それらはScalaの構造型と同じことをすることを意図していますか？プロトコルは構造タイプ（パフォーマンス、柔軟性、コードの明確さなど）に対してどのような利点がありますか？それらはリフレクションを通じて実装されていますか？
• Scalaとの相互運用性に関する質問：Scalaの構造型の代わりにプロトコルを使用できますか？それらをScalaで拡張できますか（「拡張」用語をプロトコルに適用できる場合）？

閉じることができるものと、前者を受け取り、関数の実行後に「閉じる」が確実に閉じられるようにする関数を受け取る単純なヘルパーメソッドを作成しようとしています。

たとえば、次のように使用したいと思います。

私の実装は

しかし、この単純なテストをコンパイルしようとすると:

コンパイラは次のように文句を言います：

推論された型引数 [java.io.FileOutputStream] は、メソッド クロージングの型パラメーターの境界に準拠していません [T <: AnyRef{def close: Unit}]

理由はありますか？

タイトルは基本的にそれを言います。

new Object {def foo = "bar"}たとえば、isInstanceOf[<structural_type_here>]呼び出しでのタイプを使用する方法はありますか?

同じシグニチャを持ついくつかのメソッドを持つが、宣言されたJavaインターフェイスに対応しないクラスがいくつかある場合があります。たとえば、JTextFieldとJButton（のいくつかの他の中で javax.swing.*）の両方にメソッドがあります

ここで、そのメソッドを持つオブジェクトを使用して何かを実行したいとします。次に、インターフェイスが必要です（または、自分で定義することもできます）。

私が書くことができるように：

しかし、悲しいことに、私はできません：

このキャストは違法です。クラスがそのインターフェースを実装することを宣言していないので、コンパイラーはそれがではないことを知っています...しかしそれは「実際に」それを実装します。JButton CanAddActionListener

これは不便な場合があります。Java自体がいくつかのコアクラスを変更して、古いメソッドで作成された新しいインターフェイスを実装しています（String implements CharSequenceたとえば）。

私の質問は：なぜこれがそうなのか？クラスがインターフェイスを実装することを宣言することの有用性を理解しています。しかし、とにかく、私の例を見ると、なぜコンパイラーは、クラスJButtonがインターフェース宣言を「満たして」（その内部を見て）、キャストを受け入れることができないと推測できないのでしょうか？それはコンパイラの効率の問題ですか、それとももっと根本的な問題がありますか？

答えの要約：これは、Javaが何らかの「構造的型付け」（ダックタイピングのようなものですが、コンパイル時にチェックされます）を考慮に入れていた可能性がある場合です。そうではありませんでした。いくつかの（私にはわかりませんが）パフォーマンスと実装の難しさは別として、ここにははるかに基本的な概念があります。Javaでは、インターフェース（および一般的にはすべて）の宣言は、単に構造的（これらのシグニチャ）がセマンティック：メソッドは特定の動作/意図を実装することになっています。したがって、あるインターフェースを構造的に満たす（つまり、必要なシグニチャーを持つメソッドを持っている）クラスは、必ずしも意味的に満たすとは限りません。（極端な例：メソッドさえない「マーカーインターフェース」を思い出してください！）したがって、Javaは、これが明示的に宣言されているため（そしてそれだけのために）、クラスがインターフェースを実装していると断言できます。他の言語（Go、Scala）には他の哲学があります。

このSOの質問へのフォローアップ。

コードがあるとします

この関数により、オブジェクトparamは次の名前のメソッドを呼び出します。foo

[編集]

以下が可能かどうか疑問に思っていました（反射の有無にかかわらず）

• paramはコンパイル時に固定され、関数の名前 (この場合fooは ) は実行時に提供されます。
• 両方paramと関数の名前がfoo実行時に提供されます
• paramコンパイル時に固定され、関数の名前、関数のパラメーター、値、および戻り値の型は実行時に提供されます。

構造型付けはすでにリフレクションを使用していることに気付きました。だから私の質問は、Scala がそれを処理できるかどうか、またはコードで明示的にリフレクションを使用しているかどうかです。3 つ目は、 ASMライブラリを使用できるリフレクションが必要だと思います。

問題を言葉で説明する代わりに、私がやりたいことを示すScalaインタープリターセッションを紹介します。

したがって、基本的には、特定の型のサブクラスであり、シグネチャを持つメソッドも含むパラメータで型を定義したいと思います def name():String。

注：クラス階層はすでに複雑になっているため、この方法で実行しようとしています。これを考えると、私は追加しないか、それを回避できるParentWithName abstract classかどうかを好みます。trait

ジェネリックにネストされた構造型の奇妙な構造を誰かが説明できますか:

この例は Scalaz ライブラリからのものです: Functor.scala

なぜこの構造が必要なのですか？書くのは簡単ではありません：

また

それらすべてに共通するいくつかのプロパティを持ついくつかのオブジェクトがあります。例えば：

オブジェクトAはタイプXで、​​10個のプロパティがあります

オブジェクトBはタイプYで、15個のプロパティがあります

オブジェクトCはタイプZで、7つのプロパティがあります

これらのオブジェクトはすべて、共通の「名前」、「署名」、および「チェックサム」プロパティを持っています。「name」、「signature」、「checksum」プロパティを含む任意のタイプのオブジェクトを受け入れることができる静的ヘルパーメソッドを作成しようとしています。それは可能ですか、それとも実際に3つの異なるメソッド（各タイプのオブジェクトを受け入れるための1つ）が必要ですか？

編集-その価値については、これらのオブジェクトがWebサービスを介して私に公開されていることについては言及しませんでした。

関数が構造型を受け入れる場合、次のように定義できます。

また

次に、その関数を次のように使用できます。

私の例でscalacによって生成されたクラスを（Javaに）逆コンパイルすると、の引数doTheThingsは型Objectであり、実装はリフレクションを使用して引数のメソッドを呼び出すことがわかります（つまりduck.quack）

私の質問は、なぜ反射なのかということです。リフレクションの代わりにanonymousを使用してinvokevirtualを使用することはできませんか？

これが私の例の構造型呼び出しを変換（実装）する方法です（Java構文ですが、要点はバイトコードです）：