4

免責事項

タイトルとは裏腹に、これは純粋な質問であり、Emacs/Vi フレームワークの試みではありません。

環境

Haskell を数か月使用して、10K までの小さな LOC インタープリターを作成しました。昨年、私は Clojure に切り替えました。かなり長い間、私は Clojure の型の欠如に悩まされていました。その後、Clojure で defrecords を使用するようになり、Clojure の defprotocols に切り替えました。

私はデフプロトコルが本当に好きです。実際には2種類以上。

私は今、Clojure 関数のドキュメンテーション文字列のために、次のように指定するところまで来ました。

* the protocols of the inputs
* the protocols of the outputs

これを使用すると、アドホック型システムができたように見えます (コンパイラーはチェックしていませんが、人間がチェックしています)。

質問

私が見逃している型について何かがあるのではないかと思います。型はプロトコルを介して何を提供しますか?

4

3 に答える 3

3

質問に疑問...

あなたの質問「型はプロトコルを介して何を提供しますか?」私には厄介に思えます。タイプとプロトコルは垂直です。彼らはさまざまなことを説明しています。タイプ/レコードはデータの構造を定義し、プロトコルはいくつかの動作または機能の構造を定義します。そして、この質問が奇妙に思える理由の一部は、これらのことが相互に排他的ではないということです! 型にプロトコルを実装させることで、プロトコルが記述する動作/機能を型に与えることができます。実際、あなたのコンテキストから、あなたがプロトコルを使用していたことが明らかになったので、どのようにプロトコルを使用たのか疑問に思う必要があります。私の推測レコードでそれらを使用してきた(またはおそらく具体化して)が、プロトコルと(定義)タイプを一緒に簡単に使用できるということです。

私には、あなたはここでリンゴとオレンジを比較したようです. わかりやすくするために、リンゴとリンゴ、オレンジとオレンジをいくつかの異なる質問で比較してみましょう。

プロトコルはどのような問題を解決し、代替手段とそれぞれの長所/短所は何ですか?

プロトコルを使用すると、さまざまな型でさまざまな方法で動作する関数を定義できます。これを行う他の唯一の方法は、マルチメソッドと単純な関数ロジックです。

  • マルチメソッド: 非常に柔軟であることに価値があります。ディスパッチ関数として渡すことにより、タイプに基づいて動作をディスパッチできtypeますが、ディスパッチには他の任意の関数を使用することもできます。
  • 内部関数ロジック: 関数定義の条件文の型を (もちろん) 手動でチェックして、異なる型が与えられた場合に異なる処理方法を決定することもできます。これは、マルチメソッド ディスパッチよりも原始的であり、拡張性も低くなります。単純な場合を除いて、マルチメソッドが優先されます。

プロトコルには、高度に最適化された JVM クラス/メソッド ディスパッチに基づいているため、パフォーマンスが大幅に向上するという利点があります。さらに、プロトコルは式の問題に対処するように設計されており(よく読んでください)、優れたモジュール式の拡張可能な API を作成するための非常に強力なツールとなっています。

(def) レコードまたは (def) 型の具体化の利点/欠点は何ですか?

data の構造を指定する方法については、いくつかのオプションを利用できます。

  • (def)records: 「アプリケーション ドメイン情報を表す」のに適した型を生成します ( http://clojure.org/datatypesから; 読む価値があります)
  • (def)types: 標準のコレクション型など、「実装/プログラミング ドメインのアーティファクト」を作成するための軽量型を生成します。
  • reify: 1 つ以上のプロトコルを実装する匿名型で 1 回限りのオブジェクトを構築します。良い... プロトコルを実装する必要がある1回限りのもの

実際には、レコードは clojure のハッシュ マップのように動作しますが、プロトコルを実装して属性検索を高速化できるという追加の利点があります。便利なことに、 は を介し​​て拡張可能のままassocですが、この方法で追加された属性はコンパイルされたルックアップのパフォーマンスを共有しません。これが、これらの構成がアプリケーション ロジックの実装に便利な理由です。deftype を使用すると、余分なバゲージを実装しないため、実装/プログラミング ドメインの側面で有利であり、これらのケースでの使用がよりクリーンになります。

于 2015-01-11T07:34:04.220 に答える
0
  • 機械チェック
  • 型推論(他のドキュメントから生成されたプロトコルの一部を取得しません)
  • パラメトリックポリモーフィズム(パラメーター化されたプロトコル/ジェネリックスを使用したプロトコルは存在しません)
  • 高階プロトコル(プロトコルを返す関数のプロトコルは何ですか?)
  • コード/定型文の自動生成
  • 自動化ツールとの相互運用
于 2012-05-23T01:24:58.123 に答える
0

プロトコルはインターフェースを作成し、インターフェースはタイプへのインターフェースです。Haskellのような言語で期待するよりもはるかに厳密ではありませんが、タイプのいくつかの側面を説明しています。

于 2012-05-22T23:48:47.260 に答える