问题标签 [subtyping]

我最近在关系数据库设计中发现了子类型/超类型方法，因此提出了这个问题：这是与子类型/超类型设计方法混合的正确设计吗？

在我提到persons和organisations作为两种不同的类型之前。我知道拥有andparty的超类型是一种更好的方法。现在，解决了这个问题，添加and both apply for和 for ，从而将它们连接到 supertype 。peopleorganisationadressesadditional_addressesorganisationspersonsparties

此外，我需要记录不同的人群，employees比如projectcontacts和suppliercontacts。这些都是不同类型的persons, 在party. 这是加入表格persons以实现此目标的正确方法吗？suppliersand 也一样debtors，链接到organisation表格，因为supplierand debtorsare always organisations。

我相信这是一种很好的设计方式，但我可能会错过主键和外键的一些内容，尤其是在查看SupplierContacts. 有一个外键partyid应该引用a person，也有一个外键supplierid，但这也引用了自己表中supplierid的某个。partyid能够从该表中查询信息不是一项非常艰巨的工作吗？这种设计是否合适？

我主要担心的是，许多表需要引用一个人或一个组织，而不是到处都有两个外键，因为我存储了一个person OR an的记录，所以始终留下一个 NULL organisation，现在我只有一个外键：partyid.

这是我作业中的问题之一，这完全让我感到困惑。该问题询问编译器是否会报告错误。我了解协变和逆变如何与单一类型一起工作。

以上是我的想法，如有错误请指正。

这一行 A 和 B 都是类型参数位置，应该翻转，B 应该是 B >: Dog[U,T,V]，但是对于程序的其他部分，我不知道发生了什么。

假设我有一个名为 Shape 的基类。然后是一些子类，例如圆形和方形。

然后让我们在另一个名为 GetShape 的类中创建一个方法：

好吧，我的想法是，我可以传入一个 shapeType，然后返回一个强类型的 Shape 子类。上面的例子是对真实代码的大规模简化，但我认为它明白了这一点。

那么当我调用这个方法时它看起来像

唯一的问题是它甚至不会运行，因为它需要强制转换。

这实际上会起作用：

我对那个演员并不疯狂，我怎样才能避免它并且仍然完成一种让方法返回基类的方法，以便我可以返回任何兼容的子类。

subtype我对和之间的关系有一些了解subclass，但我不确定它们是否正确。

具体类（不是通用/高阶类）

如果我声明一些具体的类或类型，用 Java 或 Scala 说：

如果 classA是 class 的子类B，那么 typeA必须是 type 的子类型B？

而且，如果 typeA是 type 的子类型B，那么 classA是 class 的子类B吗？（假设A并且B都是类）

但只有当它是具体的类或类型时它们才是真的

高阶类/类型

但是对于高阶类型，这不是真的，对吧？说：

那么 typeA[String]是 type 的子类型A[Object]，但A[String]不是 的子类A[Object]，对吧？

考虑这个例子：

我对“HELLO, WORLD!”的输出感到惊讶。为什么输出不是“你好，世界！” 还是编译错误？

我刚开始学习 Java 上的通配符和子类型，并尝试测试我学到的东西。

认为：

主要：

我不明白为什么我不能使用下界通配符访问成员 y，而可以使用上限通配符。我错过了什么吗？

我对多次浏览 Rust 文档的标记部分和关于子类型和方差的维基百科文章感到愚蠢，却没有提高我对生命周期子类型关系的理解。

我想我只是习惯了“典型的 OOP 风格”子关系，例如“Cat <: Animal”，意思是“Cat 是 Animal 的子类型”，其中“S 是 T 的子类型”意味着“任何术语 S 都可以安全在预期 T 类型术语的上下文中使用”。到目前为止，一切都很好。

但这如何适用于生命周期？现在在 Rust 中定义的方式显然是 (*)

(#1) 'a <: 'b <=> 生命周期 a 不长于生命周期 b。

你可能会想“当然就是这个意思！” 可能是因为 <: 看起来类似于小于运算符，或者可能是因为“sub”让您想到子集，而较短的寿命肯定是较长寿命的一个子集。但是，如果'a 不长于'b，'a 真的是'b的子类型吗？让我们尝试应用 Wikipedia 对子类型关系的定义：

(#2) 'a <: 'b <=> 生命周期 a 可以安全地用于预期生命周期 b 的上下文中。

我的问题是我无法调和这一点。你如何从#2 到#1？因为对我来说，这似乎是一个矛盾...如果您期望某物至少在 b 内还活着，并且您的某物的生命期 a 比 b 短，那么您显然不能在某物的生命期为 b 的情况下使用它是必需的，可以吗？只是我，还是我们把一生的子类型关系弄错了？

编辑：(*) 根据#rustIRC 频道中的 Ms2ger，情况就是这样。它还符合Items迭代器中使用的逆变生命周期标记的文档。

Edit2：ConvariantLifetime 和 CovariantLifetime 标记已被删除。我们现在在标记模块中有PhantomData一个替代品。

根据此答案末尾的注释，看起来子类型和继承在 Java 中是不同的概念。它是什么？只有当类声明包含extends ...子句时才继承？如果是这种情况，那么一个类将不会从 Object 继承，即使它是它的子类型，对吗？

假设我有一个简单的类型类，它的实例会给我某种类型的值：

我有一些例子：

现在我有一个类似（但不相关）的类型类，它做同样的事情，但它的类型参数是协变的：

在它的伴生对象中，我们告诉编译器如何从我们的非协变类型类的实例中创建实例：

现在我希望implicitly[GiveMeA[Foo]]编译得很好，因为只有一种方法可以得到GiveMeA[Foo]我们这里的给定部分。但它没有（至少不是在 2.10.4 或 2.11.2 上）：

如果我们摆脱不相关的GiveMeJustA实例，它会起作用：

尽管事实上我们无法应用GiveMeA.fromGiveMeJustA此实例来获取 a GiveMeA[Foo]（或 的任何子类型GiveMeA[Foo]）。

这对我来说似乎是一个错误，但我可能遗漏了一些东西。这有道理吗？有没有合理的解决方法？

关于 Isabelle 中的子类型的问题在这里非常冗长。所以我的简单问题是，如果我将 A 定义如下，我如何将类型 B 定义为 A 的子类型：

通过这样做，我想让 B 类型的元素可以访问在 A 上定义的所有操作和关系（它们未在此处打印）。

一个更复杂的例子是将 B 和 C 定义为 A 的子类型，这样 B 和 C 是不相交的，并且 A 的每个元素要么属于 B 类型，要么属于 C 类型。

谢谢