问题标签 [self-type]

除了继承方面，以下类模板之间是否有区别：

我想在和之间分配责任TraitA，TraitB但没有后者，前者就无法运作。

你会如何表达这个意图？对我来说，解决方案 [2] 将是更自然的方法。但是，我不想让实施者承担混合需要混合的内容。

我有一个trait，它接受一个类型参数，我想说实现这个trait的对象也会符合这个类型参数（使用泛型，为了Java的兼容性）

以下代码：

给我以下错误：

如果我将 Common 更改为：

然后错误消失。

为什么我必须在每个非具体类型中重复相同的声明。如果我有一个基类，并说“扩展 Comparable”，我不必在每个派生类型中重复“扩展 Comparable”，只要具体类实现 compareTo 方法。我想这里应该是一样的。我只是说扩展 HandleOwner 的类型也是SELF，编译器应该接受它，并考虑它，而不需要每个非具体子类型再次重复相同的事情。

A 这样做是为了避免必须使用类转换，但我将从字面上扩展这个特性的每个类，我不认为我应该重复这个声明数百甚至数千次！

我了解显式类型的自引用的用途：

在正文中，self是一个别名，this但具有更精确的类型T with T2。

现在，我在代码中看到了这一点：

也就是说，没有附加类型信息的显式自引用。在这种配置中，是否存在self不只是别名的情况this？

鉴于Outer类及其Inner类的抽象定义，我想实例化trait 中Inner1定义的具体类。Outer1

Scala 编译器过早终止编译，给我以下错误消息：“错误：无法实例化类 Inner1，因为它不符合其自身类型 Outer1.this.Inner1 和 Outer1.this.Inner_Tp”。为什么？

毕竟Inner1类是在一个抽象上下文中定义的，这是它的Outer1特征。我想推迟 的定义，type Inner_Tp直到特征混入某个具体的类。

我有这种情况

我正试图让这样的工作：

但这只是给了我"error: Sup is not an enclosing class"......我也尝试过type Sup = this.type，但它仍然不起作用。

无论如何在用作私有范围参数时为我的外部对象实现一个不错的快捷方式？我确实想保留对象的长名称，而且我有很多私有方法，这就是为什么它真的妨碍了我。

我正试图围绕 scala 中的抽象和显式自我类型。让我们考虑这个例子：我想为可扩展树创建一个基础，就像这样简单：

但是，我希望能够使用一些方法扩展树节点并使用这些方法，例如：tree.children foreach { _.newMethod() }

为此，我尝试过：

A.this.type: FAIL

工作变体非常笨拙。

B. 抽象类型：FAIL

据我了解，由于路径特定类型不匹配，根本不起作用。

C. 类型参数（泛型）：OK

工作正常，但在派生类中维护不太好。

任何想法如何使前两个变体在没有大量代码的情况下工作？

此外，使用 this.type 我遇到了实施问题。

谢谢！

我有两个从抽象基类继承的案例类。我想在抽象基类上定义一些方法，这些方法使用继承案例类上的复制方法（因此返回子类的实例。）有没有办法使用自我类型来做到这一点？

示例代码：

由于这个问题，我已经弄清楚了如何获得我想要的结果： How to use Scala's this typing, abstract types, etc. to implement a Self type? 但它涉及向 BaseClass 添加一个 makeCopy 方法，并在每个子案例类中调用 copy 来覆盖它，并且语法（尤其是对于 Self 类型）相当混乱。有没有办法用 Scala 的内置自键入来做到这一点？

Scala 有两种表达对象组合的工具：原始的自我类型概念和众所周知的琐碎组合。我很好奇我应该在哪些情况下使用。

它们的适用性存在明显差异。自我类型要求你使用特质。对象组合允许您在运行时使用 var 声明更改扩展。

抛开技术细节，我可以想出两个指标来帮助对用例进行分类。如果某些对象用作复杂结构（例如树）的组合器，或者仅具有几个类似类型的部件（1 辆汽车与 4 个轮子的关系），则应该使用组合。有极端相反的用例。让我们假设一个特征变得太大而无法清楚地观察它并且它被分裂了。在这种情况下，您应该使用自类型是很自然的。

这些规则不是绝对的。您可能需要做额外的工作来在这些技术之间转换代码。例如，您可以用 Product4 上的自键入替换 4 个轮子组合。您可以使用Cake[T <: MyType] {part : MyType}而不是Cake { this : MyType => }蛋糕模式依赖项。但这两种情况似乎都违反直觉，并且会给您额外的工作。

虽然有很多边界用例。一对一的关系很难决定。是否有任何简单的规则来决定哪种技术更可取？

自类型使您的类抽象，组合使您的代码冗长。self-type 给你混合命名空间的问题，也给你额外的免费打字（你不仅得到了两种元素的混合物，还有被称为汽油炸弹的汽油发动机油混合物）。

我该如何选择它们？有哪些提示？

更新：

让我们讨论以下示例：

适配器模式。它对自编和组合方法有什么好处？

可能重复：
scala 自类型和特征子类之间有什么区别？

我将自注释理解为对编译器的承诺，程序员表明一个特征将与带注释的特征混合。例如：

在前面的示例中，第三个表达式失败，因为我们没有为新实例设置有效的 X。显然，最后一个效果很好。到现在为止还挺好。现在，让我们看另一个涉及对象的示例。

我知道该对象正在实例化失败，并带有 X 承诺（我们现在正在创建一个带有未来承诺的实例！），如下几行所示，其中的特征已稍作修改：

那么，对象自注释意味着什么？

我必须在使用蛋糕模式的项目中集成一些宏。这种模式使我们能够避免大量进口以及其他优势，因此我们希望保留它。现在，我们在主干外测试的一些实验性宏遇到了问题。首先，让我们展示一个名为 Cake 的虚拟系统：

APiece定义了一个类，BPiece应该是一个使用 APiece 定义的类的宏，最后，CPiece调用该宏。我说 BPiece 应该是一个宏，因为我无法为它编写实现代码。我尝试了几种方法，但总是因以下错误而崩溃：

阅读宏代码可以猜测将宏包含在静态模块中是必要的。有没有办法部署使用系统结构的宏？