设计F＃库以供F＃和C＃使用的最佳方法

我试图在F＃中设计一个库。 图书馆应该对F＃和C＃都很友好。

这就是我被卡住的地方。 我可以让F＃友好，或者我可以让C＃友好，但问题是如何使它对两者都友好。

这是一个例子。 想象一下，我在F＃中有以下功能：

let compose (f: 'T -> 'TResult) (a : 'TResult -> unit) = f >> a

这从F＃完全可用：

let useComposeInFsharp() =
    let composite = compose (fun item -> item.ToString) (fun item -> printfn "%A" item)
    composite "foo"
    composite "bar"

在C＃中， compose功能具有以下签名：

FSharpFunc<T, Unit> compose<T, TResult>(FSharpFunc<T, TResult> f, FSharpFunc<TResult, Unit> a);

但是我当然不想在签名中使用FSharpFunc ，我想要的是Func和Action ，就像这样：

Action<T> compose2<T, TResult>(Func<T, TResult> f, Action<TResult> a);

为了达到这个目的，我可以像这样创建compose2函数：

let compose2 (f: Func<'T, 'TResult>) (a : Action<'TResult> ) = 
    new Action<'T>(f.Invoke >> a.Invoke)

现在，这在C＃中是完全可用的：

void UseCompose2FromCs()
{
    compose2((string s) => s.ToUpper(), Console.WriteLine);
}

但是现在我们compose2来自F＃使用compose2问题！ 现在，我必须将所有标准的F＃ funs包装到Func和Action ，如下所示：

let useCompose2InFsharp() =
    let f = Func<_,_>(fun item -> item.ToString())
    let a = Action<_>(fun item -> printfn "%A" item)
    let composite2 = compose2 f a

    composite2.Invoke "foo"
    composite2.Invoke "bar"

问题：我们如何才能为用F＃和C＃用户编写的F＃库实现一流的体验？

到目前为止，我不能提出比这两种方法更好的东西：

对于第一种方法，我会做这样的事情：

我认为命名空间的第二种方法可能会让用户感到困惑，但是你有一个程序集。

问题：这些都不是理想的，也许我缺少某种编译器标志/开关/属性或某种技巧，有更好的方法来做到这一点？

问题：是否有其他人试图实现类似的目标？如果是的话，你是如何做到的？

编辑：澄清，这个问题不仅是关于函数和代表，而是一个C＃用户的F＃库的总体经验。 这包括C＃原生的命名空间，命名约定，习惯用语等。 基本上，C＃用户不应该能够检测到该库是在F＃中编写的。 反之亦然，F＃用户应该像处理C＃库一样。

编辑2：

从目前的答案和评论中我可以看出，我的问题缺乏必要的深度，可能主要是由于仅使用了一个F＃和C＃之间的互操作性问题出现的例子，函数问题是一个值。 我认为这是最明显的例子，所以这让我用它来提问，但同样给人的印象是这是我唯一关心的问题。

让我提供更具体的例子。 我已阅读了最优秀的F＃组件设计指南文档（非常感谢@gradbot！）。 如果使用的话，文件中的指导方针确实解决了一些问题，但不是全部。

该文件分为两个主要部分：1）针对F＃用户的指南; 和2）针对C＃用户的指导原则。 它甚至没有试图假装有可能有一个统一的方法，这正好回应了我的问题：我们可以针对F＃，我们可以针对C＃，但是针对两者的实用解决方案是什么？

提醒一下，我们的目标是在F＃中创建一个库，并且可以从F＃和C＃语言中惯用地使用这些库。

这里的关键词是惯用的。 问题不在于只能使用不同语言的库的通用互操作性。

现在来看我从F＃组件设计指南直接获取的示例。

// library
module Foo
let bar() = ...
let zoo() = ...


// Use from F#
open Foo
bar()
zoo()

[<AbstractClass; Sealed>]
type Foo =
    static member bar() = ...
    static member zoo() = ...

我认为这应该足以证明我的问题的性质。

顺便提一下，指南也有部分答案：

...开发用于vanilla .NET库的高阶方法的通用实现策略是使用F＃函数类型编写所有实现，然后使用委托作为实际F＃实现上的薄外观创建公共API。

总结。

有一个明确的答案：没有编译器技巧，我错过了。

根据指导文档，似乎首先为F＃创作，然后为.NET创建外观包装是合理的策略。

那么这个问题的实际执行仍然存在：

如果我的解释是正确的，Tomas建议使用单独的名称空间应该足够了，应该是一个可接受的解决方案。

我想我会同意，因为命名空间的选择是这样的，它不会让.NET / C＃用户感到意外或困惑，这意味着它们的命名空间应该看起来像它是它们的主命名空间。 F＃用户将不得不承担选择特定于F＃的名称空间的负担。 例如：

Daniel已经解释了如何定义你编写的F＃函数的C＃友好版本，所以我会添加一些更高级别的评论。 首先，您应该阅读F＃组件设计指南（由gradbot引用）。 这篇文档解释了如何使用F＃设计F＃和.NET库，它应该回答你的许多问题。

使用F＃时，基本上有两种类型的库可以编写：

在你的问题中，你问如何将函数组合作为一个.NET库公开，但我认为像你的compose这样的函数是从.NET库角度来看太低级别的概念。 你可以将它们暴露为使用Func和Action ，但这可能不是你如何设计一个普通的.NET库（也许你会使用Builder模式或类似的东西）。

在某些情况下（即设计与.NET库风格不太吻合的数值库时），设计一个在单个库中混合使用F＃和.NET风格的库是非常有意义的。 做到这一点的最佳方式是使用普通的F＃（或普通的.NET）API，然后为其他风格的自然使用提供包装。 包装可以在一个单独的名称空间（如MyLibrary.FSharp和MyLibrary ）。

在你的例子中，你可以将F＃实现留在MyLibrary.FSharp ，然后在MyLibrary命名空间中添加.NET（C＃ - 友好）包装器（类似于Daniel发布的代码），作为某些类的静态方法。 但是，.NET库可能会比函数组合更具体的API。

你只需要用Func或Action包装函数值（部分应用的函数等），其余的都会自动转换。 例如：

type A(arg) =
  member x.Invoke(f: Func<_,_>) = f.Invoke(arg)

let a = A(1)
a.Invoke(fun i -> i + 1)

因此，在适用的情况下使用Func / Action是有意义的。 这是否消除了您的担忧？ 我认为你提出的解决方案过于复杂。 你可以用F＃编写你的整个库，并从F＃和C＃中使用它（我一直这么做）。

另外，在互操作性方面，F＃比C＃更灵活，所以当这是一个问题时，通常最好遵循传统的.NET风格。

编辑

我认为，只有当它们互补或F＃功能不可用于C＃时（例如依赖于F＃特定元数据的内联函数），才能保证在单独的命名空间中生成两个公共接口所需的工作。

顺便提一下你的观点：

您采取的策略取决于您的库的类型和大小，但根据我的经验，在F＃和C＃之间找到最佳位置需要较少的工作（长期而言），而不是创建单独的API。

虽然它可能会是一个矫枉过正的问题，但您可以考虑使用Mono.Cecil编写应用程序（它在邮件列表上具有很棒的支持），可以自动执行IL级别的转换。 例如，您使用F＃风格的公共API在F＃中实现您的程序集，然后该工具将生成一个C＃ - 友好的包装器。

例如，在F＃中，显然使用option<'T> （ None ，具体而言），而不是像C＃中那样使用null 。 为这个场景编写一个包装器生成器应该相当简单：包装器方法将调用原始方法：如果它的返回值是Some x ，则返回x ，否则返回null 。

当T是一个值类型时，您将需要处理该情况，即不可为空; 你将不得不将wrapper方法的返回值封装到Nullable<T> ，这会让它有点痛苦。

再次，我相当确定它会在您的方案中写出这样的工具，也许除了定期研究这种库（可以从F＃和C＃两者无缝使用）之外。 无论如何，我认为这将是一个有趣的实验，我甚至可能会在某个时候进行探索。

上一篇: Best approach for designing F# libraries for use from both F# and C#

下一篇: F# vs OCaml: Stack overflow