为什么Scala支持阴影变量？

Question

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

Answer 1

正如提醒一样：​​变量，方法或类型在内部范围内声明时，被称为 shadow 另一个变量，方法或同名类型，这使得它无法以不合格的方式（或者，有时甚至根本）引用外部范围实体。 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
}

这会产生一种非常讨厌的语言。