使用 Scala 的结构类型有哪些性能和维护注意事项？
我的同事基于这两个理由都不让我使用它们。 :(
My co-workers wont let me use them on both grounds. :(
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我的同事基于这两个理由都不让我使用它们。 :(
My co-workers wont let me use them on both grounds. :(
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
性能考虑因素是结构类型中的方法是通过反射调用的，这在 JVM 上比常规方法调用慢很多。有关详细信息，请参阅此答案和评论。
A performance consideration is that the methods in a structural type are called via reflection, which is a lot slower on the JVM than a regular method call. See this answer and comments for detailed info.
我发现当我需要结构类型时，几乎总是因为我想要使用的库设计不正确（例如，在 StringBuilder / StringBuffer 等情况下缺少超类）。
因此，如果您出于其他原因想要使用结构类型，则可能是设计问题 - 这会比配置或性能考虑更严重。 Scala 的类型系统非常强大，使用结构类型有点像“放弃”而用“正常”方式来实现它。因此，如果您有一些代码似乎“需要”结构类型，请尝试分析为什么会这样，并且可能询问社区是否可以改进（
顺便说一句，每个人都倾向于过度使用他刚刚“理解”的功能，例如，初学者一旦掌握了概念，就会疯狂地进行模式匹配，即使有更好的方法（例如，在诸如 map、flatMap、foreach...等选项功能的情况下）。
I found that when I need structural types, it's almost always because a library I wanted to use isn't designed properly (e.g. missing superclasses in cases like StringBuilder / StringBuffer).
So if you want to use structural types for other reasons, it might be a design problem - which would be more serious than configuration or performance considerations. Scala's type system is powerful, and using structural types is a little bit like "giving up" to get it right with "normal" means. So if you have some code that seems to "require" structural types, try to analyse why it is that way, and maybe ask the community if it can be improved ( https://codereview.stackexchange.com/ seems like a good place for this) if you are stuck.
BTW, everybody tends to overuse a feature he just "grokked", e.g. beginners pattern match like crazy once they get the concept, even if there are better ways (e.g. in case of Option functions like map, flatMap, foreach...).
它还取决于您使用它们的程度，M. Odersky 和 G. Dubochet 在他们的报告中提出了一些基准。
It also depends in how much you use them, M. Odersky and G. Dubochet have some benchmarks in their report.