问题标签 [traits]

我正在实现一个数据结构，并希望用户能够使用任何类型作为键，只要他提供了一个合适的键类型来包装它。我有这种键类型的特征。这个想法是从基类型到键类型进行隐式转换，反之则（实际上）只使用基类型。特征如下所示：

呼叫站点代码可能如下所示：

计划是类型的值K应该隐式转换Key[K]为排序的值，或者应该分别隐式使用排序Key[K]，所以一切都应该解决。当然，没有办法base2key在 trait 本身中实现隐式。或者是否存在，也许使用隐式传递的类清单？考虑到这一点，我找不到任何参考资料。

是否有可能以某种方式静态断言任何类型扩展Key[T]都将带有隐式转换T => Key[T]？可悲的是，伴生对象不能有抽象方法。

假设这可行，整个企业是否可行，或者所述用例是否需要多个链接的隐式转换？（正如我所读到的，链接不会发生。）

附录：Node(key : K, ...)有了上面的定义，我可以通过 using 对（下K <% Key[K]）的序列进行排序sortWith(_.key <= _.key)，但不能使用sortBy(_.key). 因此，显然，从Kto的转换是Key[K]隐式发生的，即使我从未在任何地方声明它，但没有OrderingonKey[K]隐式可用。这里发生了什么？

我正在使用 Jersey 在 Scala 中实现 JAX-RS 服务。我想为 Json 提供者提供一个通用特征，我需要知道我的提供者是否支持请求的类。由于类型擦除，在 java 中不可能在运行时知道类型参数的类。但是有可能在scala中做吗？

此代码不起作用：

有什么建议吗？在 Java 中，最好的方法是让受保护的抽象方法返回 A 的类，在 Scala 中也是如此吗？

我有一个带有一些构造函数参数的基类：

因为类变得越来越大，只有一些子类需要一些特殊的行为，所以我想将它重构为一个 trait。但是，我仍然需要访问contexttrait。我试过这个：

但是 scala 编译器说：not found: value context。我该如何解决？

什么时候将特征作为模板参数传递而不是简单地使用一些现有的特征结构如

typedef basic_ofstream< char, char_traits<char> >

对比

typedef basic_ofstream< char >?

我有一些瓦片类，我希望它们有一些共同点（特征），所以我设计tile_traits包含有关瓦片的所有基本信息，例如int_type和flag_type，如下所示：

像这样设计特征是否被视为特征块？

这不是什么大问题，而是我的兴奋，这完全有可能！我写这个小例子只是为了证明相反的情况——我期望编译器错误或其中一个值（111 或 222，我不确定）。

为什么不v被覆盖？当然，这仅在vs 是私有的情况下才有效，但仍然有效。

我刚刚被介绍给特征（Smalltalk 中的“特征”，Perl 中的“角色”）。我想用我熟悉的语言快速试验它们。Java 中是否有任何支持特征的库或扩展？

我听说 AspectJ 和 Qi4J 都支持 mixins，但我也读到 mixins 与特征不同。那么我也可以将这些库之一用于特征吗？

或者 Scala 怎么样，它与 Java 完全向后兼容，对吧？这是否支持特征？

还有其他建议吗？

最近有人告诉我，Scala 的特征不是“真正的”特征，它们实际上只是混合。不幸的是，我没有机会问他为什么。有人知道他的意思吗？

编辑： 作为“特征”的定义，我一直指的是 Nathanael Schärli 的论文和概念文件介绍了特征。大多数 mixin 和/或多重继承实现似乎缺少的一项关键功能是在导入方法时重命名方法以避免冲突/歧义的能力。斯卡拉能做到吗？

我注意到 Scala 标准库使用两种不同的策略来组织类、特征和单例对象。

1. 使用其成员是导入的包。例如，这就是您如何访问scala.collection.mutable.ListBuffer. 这种技术熟悉来自 Java、Python 等。

2. 使用特征的类型成员。例如，这是您访问该Parser类型的方式。您首先需要混合scala.util.parsing.combinator.Parsers. 这种技术并不熟悉来自 Java、Python 等，并且在第三方库中使用得不多。

我想（2）的一个优点是它组织了方法和类型，但是根据 Scala 2.8 的包对象，同样可以使用（1）来完成。为什么有这两种策略？什么时候应该使用每个？

我认为当您编写时trait T extends A，它使您只能将 traitT放在作为A. 那我为什么能装B？这只适用于你混合它的时候吗？为什么在声明类时这是不可能的？

我只是想知道使用特征来构建游戏对象在语义上是否正确。一方面，我将其视为具有关系（对象具有组件），但另一方面，我将组件视为构成对象。

例如。你有一个游戏对象。一个游戏对象本身几乎什么都不做，但是你混入其中的东西赋予了它额外的属性。组件可以是 HealthComponent（有生命值）、PhysicsComponent（模拟物理）、ClickableComponent（可以点击）。

我喜欢使用特征的想法，因为所有属性和方法都添加到原始对象上，我可以player.getHP代替player.getHealthComponent.getHP. 另一方面，我发现使用特征的命名和语义很奇怪。trait HealthComponent extends GameObject- 这没有意义。AHealthComponent属于 GameObject，它不满足is隐含的关系extend。我是否正确假设特征通常被视为其父类的特殊版本？如果是这样，我将如何命名类似上述对象的名称？