在C＃中使用F＃数据类型

问题描述

更具体地说，我真想一个不变/共享链接列表，我觉得有不可改变的地图和集将是很好了。只要我不担心核心实现，我可以轻松地添加扩展方法/子/包装它提供了合理的光滑的外部接口供自己使用。

More particularly, I really want an immutable/shared linked list, and I think having immutable maps and sets would be nice too. As long as I don't have to worry about the core implementation, I can easily add extension methods/subclass/wrap it to provide a reasonably slick external interface for myself to use.

是否有任何理由我不应该这样做呢？性能方面，配伍禁忌等？

Is there any reason I shouldn't do this? Performance, incompatibility, etc.?

推荐答案

在F＃库的类型（如设置，地图和列表）未设计为从C＃中使用，所以我不会一般建议直接使用它们。这是可以做到和一些基本的操作都将很好地工作（例如添加元素的不可变映射，如果一个成分存在检查）。不过，也有一些问题：

The types in the F# library (such as Set, Map and list) were not designed to be used from C#, so I wouldn't generally recommend using them directly. It can be done and some basic operations will work well (e.g. adding elements to an immutable map and checking if an element exists). However, there are some issues:

• F＃也有模块（功能 MapModule 为不可变的映射），并为C＃用户，你希望看到这些作为成员。

• F# also has functionality in modules (MapModule for an immutable map) and as a C# user, you would expect to see these as members.

F＃功能并不表示为 Func键< _，_> 代表，但使用一些特殊的F＃特异性的方式。这意味着使用高阶函数将是困难的。

F# functions are not represented as Func<_, _> delegates, but using some special F#-specific way. This means that using higher-order functions will be difficult.

所以，综上所述，我认为更好的方法是包装F＃的数据类型为暴露你需要一个C＃开发人员友好的方式方法的类（F＃中实现）。你可以如轻易宣布接受 Func键℃的F＃方法_，_> 委托，并调用F＃高阶函数在一个模块中

So, in summary, I think that a better approach is to wrap the F# data type into a class (implemented in F#) that exposes the methods you need to a C# developer in a friendly way. You can e.g. easily declare an F# method that takes Func<_, _> delegate and calls F# higher-order function in a module.

这篇关于在C＃中使用F＃数据类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！