問題タブ [implicit]

多くの場合、Scala の暗黙の引数に注意を払う必要はありませんが、コンパイラがどのようにそれらを自動的に提供しているかを理解しておくと非常に役立つ場合があります。残念ながら、この理解を得るのは難しいようです!

特定のコードで、暗黙的なパラメーターがどのように提供されているかを発見する一般的な方法はありますか?

理想的には、いつの日か IDE 統合によって何らかの形でこの情報が提供されるようになるでしょうが、今のところはさらに深く掘り下げる必要があると思います。任意の時点でコンパイラが選択する暗黙の定義を正確に説明するようにコンパイラに依頼する方法はありますか? これは、他のコンパイラ出力から間接的に解読できますか?

例として、スタック オーバーフローでこのような質問を読まずに、へのimplicit bf: CanBuildFrom[Repr, B, That]引数がどこから来るのかを自分で解決する方法を知りたいです!TraversableLike.map

Scalac が、クラス宣言で提供される暗黙のパラメーター リストの前に空のパラメーター リストを挿入するのはなぜですか?

scalac ソースのコメントから判断すると、これはバグではなく機能のようです。

// (implicit ... ) を ()(implicit ... ) に変換 (それが唯一のパラメータ セクションの場合)

なぜこれが行われるのか知りたいです。むしろ驚くべきことだと思います。

コンパイラー（msvc ++ express）に、コンストラクターで「文字列」をCustomStringとして変換させることはできますが、参照を使用することはできません。したがって、コンパイラが可能であると判断した場合、他の型で値を渡すことができるように、とにかく参照渡しで最適化される可能性は同じではないでしょうか。

を使用して暗黙的に変換しません

：

意思 ：

最近、Scala ブロガーの間で型クラスパターンに熱狂しているようです。このパターンでは、単純なクラスに、何らかの特性またはパターンに準拠する追加のクラスによって機能が追加されます。非常に単純化された例として、単純なクラス:

Foo トレイトに適合させることができます:

この型クラスの助けを借りて：

型クラスは通常、コンパイル時に暗黙的にキャプチャされ、Wotsit とその型クラスの両方を一緒に高階関数に渡すことができます。

（あなたが私を訂正する前に、私はそれが過度に単純化された例だと言いました）

ただし、暗黙の使用は、アイテムの正確なタイプがコンパイル時にわかっていることを前提としています。私のコードでは、多くの場合そうではないことがわかります。あるタイプのアイテム List[T] のリストがあり、それらを操作するための正しいタイプ クラスを検出する必要があります。

Scala で提案されているアプローチは、呼び出し階層のすべてのポイントに typeclass 引数を追加することです。これは、コードがスケーリングされ、これらの依存関係がますます無関係になるメソッドを介して、ますます長いチェーンに渡される必要があるため、煩わしいものになる可能性があります。これにより、Scala の目的とは逆に、コードが雑然として保守が難しくなります。

通常、これは依存性注入が介入する場所であり、ライブラリを使用して、必要な時点で目的のオブジェクトを提供します。詳細は、DI 用に選択されたライブラリによって異なります。私は過去に Java で独自のライブラリを作成しました。

問題は、型クラスの場合、コンパイル時に正確な値がわからないことです。ポリモーフィック記述に基づいて選択する必要があります。そして重大なことに、型情報はコンパイラによって消去されています。マニフェストは型消去に対する Scala のソリューションですが、マニフェストを使用してこの問題に対処する方法は、私にはまったくわかりません。

これに取り組む方法として、人々はどのような手法と Scala の依存性注入ライブラリを提案しますか? 私はトリックを逃していますか？完璧な DI ライブラリ? それとも、これが本当に問題になっているように見えるのでしょうか?

明確化

これには本当に2つの側面があると思います。最初のケースでは、型クラスが必要なポイントは、そのオペランドの正確な型がわかっているポイントからの直接の関数呼び出しによって到達されるため、十分なタイプ ラングリングとシンタックス シュガーにより、型クラスを必要な点です。

2 番目のケースでは、2 つの点がバリアによって分離されています。たとえば、変更できない API、データベースやオブジェクト ストアに保存されている API、シリアル化されて別のコンピューターに送信されている API などです。つまり、型クラスは変更できないことを意味します。オペランドとともに渡されません。この場合、型と値が実行時にしか分からないオブジェクトがある場合、何らかの方法で型クラスを検出する必要があります。

関数型プログラマーは最初のケースを想定する習慣があると思います-十分に高度な言語では、オペランドの型は常に認識可能です。David と mkniessl はこれについて良い答えを提供してくれました。私はそれらを批判したくありません。しかし、2 番目のケースは確かに存在するため、依存性注入を問題に持ち込んだのはそのためです。

暗黙的なメソッドを使用して関数を別のものに変換したい場合、いくつかの問題があります。

テスト目的で Scala 2.8 に小さな DSL を実装しています。インスタンスのさまざまなチェック (必要に応じてアサーション) をサポートする必要があります。DSL 全体は少し複雑ですが、次の単純化された例は私の問題を示しています。

最初の 2 つの println 行 (変換メソッドを明示的に呼び出した場合) はコンパイルして正常に動作しますが、最後の行 (暗黙に依存したい
Compile error: missing arguments for method b in object PimpMyFunction; follow this method with '_' if you want to treat it as a partially applied function
場合) はエラーを生成します: 「通常の」インスタンス (関数ではない) を暗黙的に変換する場合）同じように機能するため、問題はスコーピング/インポートに関連していないと思います。

エラーメッセージの指示に従って使用すればprintln((b _).isZeroIn(a0))動作しますが、DSL は非技術者を対象としているため、構文はできるだけクリーンでシンプルに保ちたいと考えています。

よりクリーンな構文をサポートする別の回避策 (b は、チェック メソッド + A => Int を既に含むアサーション トレイトを拡張するクラスである必要があります) があると思いますが、より冗長で柔軟性が低いため、暗黙の方法。

構文を回避し(b _)、引き続き暗黙を使用する方法はありますか?

私は次のクラスを持っています：

pop方法は次のとおりです。

oldHeadはへのポインタでありstruct Link、メンバーとしてvoidポインタを持っています。それで、削除することによって、oldHead私はそのvoidポインターを暗黙的に削除しているのですよね？

BruceEckelによるThinkinginC ++を読んでいますdeleteが、ポインタの種類を知る必要があるため、voidポインタを削除しても適切にクリーンアップされないと言われています。

このコードは暗黙的にvoidポインターdataを削除しているので、誰かがvoidポインターを削除するこの（暗黙の）方法がwithで削除するのと異なる理由を説明できますかdelete <void pointer>？

Iterator [A]を拡張するカスタムトレイトを作成しましたが、別のメソッドから返されるIterator[A]で作成したメソッドを使用できるようにしたいと思います。これは可能ですか？

私はまだ暗黙のこと全体に頭を悩ませようとしていて、Barオブジェクト定義にメソッドを書くようなものはあまりありません。そのようなアイテムを上記のように機能するようにラップするにはどうすればよいですか？

私はこの遺産を持っています

と

しかし、私はこれをしたい：

どうすればそれができますか？

私の考えでは、明示的なローカライズよりも暗黙的なローカライズの利点は、特定のコントロールに対してローカライズするプロパティが複数ある場合、より経済的な構文になることです。

一部のテキストをローカライズする必要がある場合は、UI にレンダリングするプロパティ (Text) を 1 つだけ持つ asp:Localize コントロールを使用します。どちらか一方を使用する理由はありますか？スタイルの好みはありますか？速度の違いはありますか？

暗黙

対

明示的