首页 > 解决方案 > Variant 与 ListVariant 类型

问题描述

我正在构建一个类型系统并有一个可以支持所有其他类型的变体类型。这是一个简单的示例,其中允许使用int32floatstr

`variant_scalar`
"hello"
NULL
2
2.7

此外,还支持变体长度的类型化数组,例如:

`int32_arrar`
[1,2]
[1,2,3]
[1]

现在我对以下两个变体列有疑问,一个仅包含变体数组项,另一个包含标量和数组性质的类型:

`variant_array`
[1,2,"hello"]
["new", [1,2]]
NULL

-------------------------------------

`variant_anything`
1
"hello"
NULL
[1,2,"hello"]

在类型系统(例如,对于数据库)中处理这个问题的正确方法是什么?应该只有一种Variant类型支持所有东西,还是应该有一种VariantArray类型支持任何东西的数组......但它必须是一个数组?

我想一个可能有用的参考是 M 语言使用的类型系统:https ://docs.microsoft.com/en-us/powerquery-m/m-spec-types 。

标签: typesvarianttype-theory

解决方案


许多不同类型的系统是有原因的。

恐怕没有适当的方法,如果不深入了解您的需求和限制,就无法回答您的问题。

一般的答案是:“您的类型越具体 - 越好(*) ”。

如果你可以在你的类型系统中表达,例如,一个长度是质数的电子邮件数组 - 那么你的类型系统将在更多情况下有用,与不能表达这种类型的系统相比......

(*)但它会带来成本:

  1. 这种类型的系统使用起来可能是一场噩梦。
  2. 这种类型的系统实现起来可能是一场噩梦。

维基百科可能不是绝对的真理,但很好地概括了这个话题:

当一种编程语言发展出一个更复杂的类型系统时,它会获得比基本类型检查更细粒度的规则集,但是当类型推断(和其他属性)变得无法确定时,这是有代价的程序员注释代码或考虑与计算机相关的操作和功能。找到一个以类型安全的方式满足所有编程实践的足够表达的类型系统是一项挑战。

我建议考虑“进化”部分。不要试图建立一个理想。建立 MVP,但是当你从实践中找出正确的方法时,你可以在以后改进它。

但是在您的特定示例中,我想您Array<T>无论如何都想实现...实际上,您说您愿意

此外,还支持变体长度的类型化数组

所以Array<Variant>应该问题不大。没有理由将T其视为any but not Variant


推荐阅读