为什么Scala 支持影子变量？

Question

我认为影子变量太危险而不能使用它们。为什么 Scala 支持这种语言结构？应该有一些强有力的理由，但我找不到它。

Answer 1

提醒一下：当一个变量、方法或类型在内部作用域中声明时，它会遮蔽另一个同名的变量、方法或类型，从而无法引用该变量、方法或类型。以不合格的方式（或者有时根本不）。 Scala 与 Java 一样，允许阴影。

我看到的一个可能的原因是，在 Scala 中，经常有许多嵌套作用域，每个嵌套作用域都相对较短（与 Java 或 C++ 相比）。事实上，块可以在需要表达式的任何地方开始，从而开始一个新的作用域。因此，平均而言，在内部作用域中使用隐藏名称更接近其声明并且不那么模糊。

此外，内联闭包通常会导致程序员在已经拥挤的作用域中需要新的变量名称。允许遮蔽还允许继续使用足够切题的描述性名称，即使它们与所有已经使用的名称相同，而不是发明其他奇怪的名称 - 比如在它们前面加上 my、local，或者（更糟糕的）_ 或单字母名称……

对于好的 IDE，阴影不再是一个问题，例如可以在源代码中突出显示 的声明和引用，光标下的变量。

这里只是我的两分钱……

Answer 2

我认为影子变量太危险而不能使用它们。

你有权随心所欲地思考。然而，由于你没有提供任何数据、研究甚至理由，所以这种观点没有任何价值。

为什么 Scala 支持这种语言结构？

因为它很有用。程序员不需要仅仅因为作用域中的某些标识符已经在使用它而发明任意标识符名称。

它也使通配符导入更加有用，因为它消除了仅仅因为第三方添加了您正在使用的标识符而导致编译中断的可能性。

应该有一些强有力的理由，但我找不到它。

为什么要有一个强有力的理由呢？它有优点，并且在没有缺点的情况下（你没有提出任何缺点），这就足够了。

编辑

在回答所解释的缺点时，我必须说这是阴影的一种特殊情况。遮蔽还会影响导入中的所有内容（通过 import 语句或通过嵌套的 package 语句）以及同一包中的所有内容。

让我们看一些例子：

// Not allowed, because it shadows List
import java.util._ 

class A {
    // Not allowed, because it shadows this, hashCode, equals, toString
    class B
}

这将是一种非常烦人的语言。