C# 用oop风格编写F#代码

我写了一个ip计算器库，将函数式和oop风格混合在一起

type IpAddr(file: string, loc: string) = 

    let location = queryIpLocation file loc
    let listRange = extractAddr location 


    member self.Calculate(addr :string) =
        validIp addr listRange

calculate方法返回记录类型：

type IpLoc =
     { ip : String
       subnet : String
       gateway : String }

然后我将库导入C#应用程序，并希望使用该类：

class Program
{
    static void Main(string[] args)
    {
        var calc = new IpAddr(@"C:\Temp\file.xml", "xxxxxxx");
        var ip = calc.Calculate("xxx.xxx.xxx.xxx");
        Console.WriteLine(ip);
        Console.ReadLine();
    }
}

calculate方法返回IpLoc类型的选项对象。现在我不知道如何处理C#中的option对象

我的目标是，用f#为公司的.net应用程序编写库，并基于C#为gui wpf编写库。为什么不仅仅是C#，

---

因为我想发现f#的力量，但这样做是个好主意

首先，我认为使用F#编写进行计算的库，然后将其封装在一个C#友好的API中，该API可以从WPF应用程序中使用是一个好主意

我假设问题是

Calculate

的结果是

option

。 通常，您可以从C#中找到处理选项值的方法。这并不难（如果您是唯一编写代码的人，这可能是一个不错的选择）。但是，C#通常不使用选项，因此您也可以将代码包装成惯用的C#

您可以使用

Unchecked.defaultof

返回

null

。从F#的角度来看，这是危险的，但有时这正是C#代码所期望的：

  member x.Calculate(b) =
    match valueIp b with
    | Some v -> v
    | None -> Unchecked.defaultof<_>

如果您想让F#库与其他.NET语言交互，请查看以下文档：

---

第一个答案-为什么要使用函数式语言来创建简单的旧OO风格代码？你当初为什么选择F#？如果你像使用C一样使用“F的力量”，你就不会从中得到任何好处。其次，库的API不需要（不应该？）使用F#特定的类型。这意味着API中没有选项。您可以在实现中使用F#的所有功能，但只公开与C#兼容的API正如您前面提到的，返回对象是一个好主意？这是什么意思？在这两种语言中，一切本质上都是一个对象。有些类型可能使用值语义，有些不使用，但它们都是对象。我认为你应该澄清你在做什么以及为什么。除非您知道为什么要使用F#以及您想向客户机公开什么，否则最终您将得到伪装成F的不太可读的C代码，我想在F#中编写数据处理，例如查询数据库表或计算一些东西。我认为对于数据处理来说，f是更好的选择，而c是更好的选择。在c#，我打字累了。但是WPF和c#的工作方式很有魅力。我想知道的是，用f#编写用于处理数据的api是个好主意吗？我听说，f#中的并行编程很神奇。@zero#u编码是

计算

返回f#选项类型的问题？如果是这样的话，请在问题中更明确地说明这一点——我认为人们投票结束它是因为他们错过了关于你正在解决的具体问题的简短说明。

  member x.Calculate(b, [<System.Runtime.InteropServices.Out>] ipLoc:byref<_>) =
    match valueIp b with
    | Some v -> ipLoc <- v; true
    | None -> false