为什么Scala支持阴影变量?

Igo*_*nko 5 scala language-construct

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

Jea*_*let 21

提醒一下:当一个变量,方法或类型在内部作用域中声明时,它被称为遮蔽另一个变量,方法或类型,因此无法在不合格的情况下引用外部作用域实体.方式(或者,有时,根本).Scala就像Java一样,允许阴影.

我可以看到的一个可能原因是,在Scala中,经常有许多嵌套的范围,每个范围相对较短(与例如Java或C++相比).实际上,块可以从预期表达式的任何地方开始,从而开始新的范围.因此,内部范围中阴影名称的使用平均来说更接近于它们的声明而且不那么模糊.

此外,内联闭包通常会导致程序员在已经拥挤的范围内需要新的变量名称.允许阴影还允许使用具有足够的地步描述性的名称保持,即使他们是一样的人已经使用的名称,而不是发明了一些神秘的名字-就像用前缀my,local或者(更糟糕的)_或单字母域名...

对于良好的IDE,阴影变得不那么严重,例如可以在源代码中突出显示光标下的变量的声明和引用.

这是我的两分钱......


Dan*_*ral 18

我认为阴影变量太危险而无法使用它们.

你有权思考你想要的任何东西.但是,由于您没有提供任何数据,研究甚至原因,因此该意见没有任何价值.

为什么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
}
Run Code Online (Sandbox Code Playgroud)

这将成为一种非常讨厌的语言.

  • 当有人在某个范围内声明变量并且此变量与外部范围中的另一个变量具有相同的名称时,他或她会使代码更复杂.跟踪每个变量的含义要困难得多.以下是"Scala编程"中的一个很好的引用:"请记住,这样的代码可能会让读者感到困惑,因为变量名称在嵌套作用域中采用了新的含义.通常最好选择一个新的,有意义的变量名称而不是遮蔽外部变量." (4认同)