有关设计 .NET API 以便将来与 F# 一起使用的提示

发布于 2024-09-04 19:00:16 字数 626 浏览 8 评论 0原文

我正在设计一个 .NET API,以允许开发人员为 3D 模拟足球创建 RoboCup 代理联赛

我对 API 如何与 C# 代码配合使用感到非常满意,但是我想使用这个项目来提高我的 F# 技能(目前基于阅读而不是练习)。

所以我想问一下,在设计一个可供 C# 和 F# 代码使用的 API 时,我应该考虑哪些事情。

一些要点。

  • 我大量使用矩阵和向量数学。这些目前是不可变的类/结构。
  • API 当前定义了一些与消费者实现的接口(例如:IAgent),使用其实现的实例(例如:MyAgent)来构造其他 API 类(例如:<代码>新客户端(myAgent))。
  • API 触发事件。
  • API 公开了一些委托类型。
  • API 包括几个枚举。

我希望尽快发布 API 的一个版本,并且如果我意识到在 F# 中使用它太困难,我不想稍后对其进行重大更改。任何建议表示赞赏。

I'm in the process of designing a .NET API to allow developers to create RoboCup agents for the 3D simulated soccer league.

I'm pretty happy with how the API work with C# code, however I would like to use this project to improve my F# skill (which is currently based on reading rather than practice).

So I would like to ask what kinds of things I should consider when designing an API that is to be consumed by both C# and F# code.

Some points.

  • I make fairly heavy use of matrix and vector math. These are currently immutable classes/structs.
  • The API currently defines a few interfaces with the consumer implements (eg: IAgent), using instances of their implementations (eg: MyAgent) to construct other API classes (eg: new Client(myAgent)).
  • The API fires events.
  • The API exposes a few delegate types.
  • The API includes several enums.

I'd like to release a version of the API as soon as possible and don't want to make major changes to it later if I realise it's too difficult to work with from F#. Any advice is appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

悲凉≈ 2024-09-11 19:00:16

最好的建议可能是尝试使用 F# 中的 API。 :)

也就是说,我认为你所拥有的听起来不错

  • 任何好的 C# API 都应该是一个相当好的 F# API
  • 在使用 delegates/Func/Action 时会遇到一些摩擦边界,但这里没有什么可以改变的,
  • 如果可能的话,枚举、事件、接口、类、结构都很好
  • ,请避免返回通常被忽略的值的 API(例如,“返回此”的流畅接口能够“链式调用”) ' - 这些导致 F# 需要大量 |>ignore

但实际上,请花一个小时尝试编写该库的 F# 使用者。很可能,在最坏的情况下,您可能会建议 F# 的一些辅助函数或扩展方法来平滑界面边界处的任何摩擦点,但我认为您所拥有的应该都很好。

The best advice is probably to try using the API from F#. :)

That said, I think what you have sounds fine

  • any good C# API should be a pretty good F# API
  • there's a little friction when using delegates/Func/Action at the boundary, but there's nothing you would change here
  • enums, events, interfaces, classes, structs are all fine
  • if possible, do avoid APIs that return values that are typically ignored (e.g. fluent interfaces that 'return this' to be able to 'chain calls' - these cause F# to need lots of |>ignores)

But really, take an hour and try writing an F# consumer of the library. In all likelihood, in the worst case, you might suggest a few helper functions or extension methods for F# to smooth over any friction points at the interface boundary, but I think what you have should all just be fine.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文