为什么不推荐使用代理? [英] Why is proxying deprecated?

问题描述

这个关于如何扩展 Scala 集合的问题让我想到了这个答案，它从 SetProxy 而不是 Set 延伸.但是 SetProxy 已被弃用！文档说(自 2.11.0 版起)由于缺乏使用和编译器级别的支持，代理已被弃用."

This question about how to extend a Scala collection led me to this answer, which extends from SetProxy rather than Set. But SetProxy has since been deprecated! The documentation says "(Since version 2.11.0) Proxying is deprecated due to lack of use and compiler-level support."

为什么没有使用代理和编译器支持?Scala 是否提供了更好的技术来完成同样的事情?是不是发现了什么致命的缺陷?

Why has proxying not gotten use and compiler support? Does Scala provide a better technique for accomplishing the same thing? Was it found to have some fatal flaw?

推荐答案

不推荐使用代理，因为它很脆弱.代理应该将所有调用转发回其他一些实现.但是，如果您向 Set 层次结构添加一个新方法会怎样——有人会记得将它添加到 SetProxy 并确保它指向它应该指向的位置吗?

Proxying is deprecated because it is fragile. A proxy is supposed to forward all calls back to some other implementation. But what if you add a new method to the Set hierarchy--will anyone remember to add it to SetProxy and make sure it points where it should?

在实践中，没有好的方法来验证代理是否真正正常运行.所以决定完全没有功能比拥有看起来有效但实际上不再有的东西要好.编译器对代理的支持可能使维护健壮代理变得足够容易，但手动方法不够健壮.

In practice, there was no good way to verify that proxies were actually functioning correctly. So the decision was made that it's better to not have the functionality at all than to have something that looks like it works but actually doesn't any more. Compiler support for proxying might make it easy enough to maintain robust proxies, but the manual approach just isn't robust enough.

这篇关于为什么不推荐使用代理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！