为什么Scala支持阴影变量？

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

2011-08-11 Igor Soloydenko

我想知道同样的事情。也许Odersky等人没有考虑就把这个行为从Java转向了Java。 – laher

我相信Odersky先生对于任何特定语言结构的决定都有一定的动机。 :) –

:)足够公平。我猜他认为编译器警告就足够了。我可以看到scalac需要编译器选项-Ywarn-shadowing，所以IDE可能也支持它。 – laher

正如提醒：变量，方法或类型被称为shadow当它在内部范围中声明时，它的另一个变量，方法或类型相同，因此无法引用外部以非限定的方式（或者有时甚至完全）使用范围实体。像Java一样，Scala允许阴影。

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

此外，内联关闭通常会导致程序员在已经拥挤的作用域中需要新的变量名称。允许阴影还允许继续使用描述性名称，即使它们与已经使用过的名称相同，而不是发明其他奇怪的名称 - 例如用my,local或（更糟糕的）_或单一的 - 字母名称...

阴影变得不那么好的IDE的问题，它可以例如在源代码中突出显示光标下变量的声明和引用。

只是我的两分钱在这里...

来源

2011-08-11 19:00:15

感谢您提供我未提供的详细回复和提醒。我想过在闭包环境中的变量阴影。你是对的，有些开发人员可能会在封闭的范围内使用相同的名称，而不是提供一些新名称。我想这些开发人员只是觉得它在使用上更加舒适。但这不是隐藏的威胁吗？我同意短范围变量名称的前缀看起来不太完美。但它使代码在大多数情况下更容易理解（特别是对于Scala新手）。如我错了请纠正我。 –

我认为影子变量是太危险使用它们。

您有权随心所欲地想。但是，由于您没有提供任何数据，研究或甚至是原因，该意见没有价值。

为什么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 
}

这将使一个很烦人的语言。

来源

2011-08-11 20:36:58

影子变量的危险性太明显，无法在最初的问题中描述。顺便说一句**我有**在关于让 - 菲利普的回答的评论中写过（可能你还没看过）。但特别为你，我会重复。 –

当某人在某个范围内声明了一个变量，并且该变量与外部范围中的另一个变量名称相同时，他或她会使代码更加复杂。跟踪每个变量的含义要困难得多。下面是'Scala编程'的一个很好的引用：“请记住，这样的代码可能会让读者感到困惑，因为变量名在嵌套作用域中采用了新的含义，通常选择一个新的有意义的变量名以遮蔽外部变量“。 –

@keykeeper好吧，我对这个论点作了回答。 –

为什么Scala支持阴影变量？

回答

相关问题