scala - 为什么 Scala 支持影子变量？

Question

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

Answer 1

提醒一下：当一个变量、方法或类型在内部范围中声明时，它会遮蔽另一个同名的变量、方法或类型，从而无法在非限定范围内引用外部范围实体方式（或者，有时，根本）。Scala，就像 Java 一样，允许阴影。

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

此外，内联闭包通常会导致程序员在已经很拥挤的范围内需要新的变量名。允许阴影还允许继续使用足够中肯的描述性名称，即使它们与已经使用的名称相同，而不是发明其他奇怪的名称——比如在它们前面加上my, local, 或（更糟的）_或单字母名称…</p>

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

这里只有我的两分钱……</p>

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
}

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