API 中枚举的使用
我正在用 C# 设计一个 API，我需要的一个函数类似于：
void CreateChild(string name, ChildType type);
其中 ChildType 定义为：
public enum ChildType { Number = 0, Text = 1 };
它应该是相当不言自明的，但本质上，它将创建相关对象的子对象，并且child 包含的值的类型将是字符串或基于枚举值的双精度数。
ChildType 枚举是公共的，因此我认为 API 的用户可以访问它。
我担心的是，某些语言无法理解签名中的枚举，并且无法对此 API 进行编程。这是值得担心的事情，还是我的担心是没有根据的？
I'm designing an API in C#, and one function I need is something along the lines of:
void CreateChild(string name, ChildType type);
Where ChildType is defined as:
public enum ChildType { Number = 0, Text = 1 };
It should be fairly self-explanatory, but essentially, it will create a child of the object in question, and the type of value that child contains will either be a string or a double based on the value of the enum.
The ChildType enum is public, thus, I assume, would be accessible to users of the API.
My concern is that some languages won't understand the enum in the signature and won't be able to program to this API. Is this something to be concerned about, or are my fears unfounded?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只要你能很好地将整数值映射到它们的含义，你就应该清楚了。任何没有枚举概念的语言仍然可以通过整数值来引用它。
使用 [Flags] 属性时要小心，因为它会使枚举的定义变得复杂。我们自动生成了包括 Java 在内的多种语言的 SDK，当我们意识到我们的一些属性是 [Flags]，但在 Java 端映射到常规枚举时，不得不有点混乱，因此 Java 无法理解组合值。
As long as you have good mappings of the integer values to what they mean, you should be in the clear. Any languages that don't have an enum concept can still refer to it by the integer value.
Be cautious about using the [Flags] attribute, since it kind of convolutes the definition of an enum. We auto-generate an SDK in several languages including Java, and had to scramble a bit when we realized that some of our properties were [Flags], but being mapped to regular enums on Java's end, so Java didn't understand combined values.
.NET Framework 本身的基类库有许多使用枚举作为参数的方法（例如，
string.Equals(string, StringComparison)）。主要的 .NET 语言当然理解它们。任何没有枚举的语言都可以使用命名常量来模拟它们。我怀疑在公共 API 中使用枚举对于其他语言来说不会有问题。
The base class library of the .NET Framework itself has many methods that use enums as parameters (e.g.,
string.Equals(string, StringComparison)). The main .NET languages certainly understand them. Any language that doesn't have enums could potentially simulate them with named constants.I suspect that using an enum in a public API would not be a problem for other languages.