12

これは質問の逆ではないことを指摘したいだけです

F# と C# の両方から使用できるように F# ライブラリを設計するための最良のアプローチ

ここでは、C# で書かれた関数型ライブラリを両方の世界で使用できるように設計する方法を尋ねているわけではありません。

このライブラリを F# から使用できるようにするための合理的な妥協点を得るために、どの設計上の選択が採用または回避されているかについての良い実践を知りたいです。

次のような慣行（例）：

  • オブジェクト階層をできるだけ単純に保つ

  • オブジェクトの状態を変更することは避けますが、新しいものを返します

  • 等...

すでにそれをやった人は、その経験を共有できますか?

サイドノート

興味深いことに、この OSS プロジェクトIronJSに注意してください。はい、F# で書かれていますが、作成者は 2 つの特殊なホストIronJS.Hosting.FSharpとIronJS.Hosting.CSharp.

4

2 に答える 2

4

使いやすさを向上させるために、F# で C# ライブラリを書き直したいと考えている日を想像してみてください。あなたがたどる可能性が高いパスは次のとおりです。

ここに画像の説明を入力

「命令型 C# --> 関数型 C# --> 関数型 F# --> 慣用的 F#」というパスに注目します。C# ライブラリが機能的であればあるほど、ライブラリは F# でより使いやすくなります。関数型スタイルは構成可能性を高めるのに役立ち、慣用的な F# コードに近づきます。これらに沿って、次のことができます。

  • デフォルトの原則で不変性を受け入れます。フィールド/プロパティを後で更新する必要があるかどうかわからない場合は、readonly最初にマークしてください。
  • 式ベースの宣言型プログラミング スタイルに従います。LINQ 操作は良い例です。
  • 不変のコレクションまたは可変コレクションを不変の方法で使用します。C# immutable collectionsの導入により、これまで以上に簡単になるはずです。

上の写真は、楽しみと利益のために F#から取ったものです のC# から F# シリーズへの移植。それらは非常に役に立ちます。C# の概念が F# でどのように表現されるかを理解すると、ライブラリの使いやすさが向上します。

C# のオブジェクト指向機能を避けることは困難です。F# の型推論は、これらの機能ではうまく機能しないことに注意してください。オブジェクト階層をシンプルに保つために、メンバーのオーバーロードの数を減らす必要があります。多数のメンバー オーバーロードは、F# 型チェッカーを簡単に混乱させます。さらに、シン F# ラッパーを C# ライブラリと共に配布しても害はありません。いくつかのメソッドをモジュール関数に変換し、アクティブ パターンを作成してオブジェクト階層を分解する必要があります。

于 2013-02-27T17:46:36.217 に答える
4

既存の .NET ライブラリとの相互運用性は F# の主要な設計目標であったため、使用するライブラリに制約はありません。

とはいえ、F# の型指定はより厳密であるため、コードがやや不格好になるパターンがいくつかあります。ビルダーパターンは1つです。

var bldr = new StringBuilder();
bldr.Append("abc"); //ignoring return value

対。

bldr.Append("abc") |> ignore //must be explicitly ignored

しかし、これは拡張メソッドまたは let バインド関数を使用して簡単に回避できます。結論: 相互運用性は、F# の強みであり、最大の成果の 1 つです。

于 2013-02-27T14:55:19.247 に答える