シャドウ変数は危険すぎて使用できないと思います。Scalaがこの言語構造をサポートするのはなぜですか?それにはいくつかの強い理由があるはずですが、私はそれを見つけることができません。
2 に答える
念のために言っておきますが、変数、メソッド、または型は、内部スコープで宣言されたときに同じ名前の別の変数、メソッド、または型をシャドウイングすると言われ、修飾されていない外部スコープエンティティを参照することはできません。方法(または、時には、まったく)。Scalaは、Javaと同じように、シャドウイングを許可します。
私が見ることができた1つの考えられる理由は、Scalaでは、ネストされたスコープが多数あり、それぞれが比較的短いことです(たとえば、JavaやC ++と比較して)。実際、ブロックは式が期待される場所であればどこからでも開始できるため、新しいスコープが開始されます。したがって、内部スコープでのシャドウイング名の使用は、平均して、それらの宣言に近く、あいまいさが少なくなります。
さらに、インラインクロージャにより、プログラマーは、すでに混雑しているスコープ内に新しい変数名を必要とすることがよくあります。シャドウイングを許可すると、他の奇妙な名前を発明する代わりに、すでに使用されている名前と同じであっても、ポイントに十分な説明的な名前を使用し続けることができmy
ます。 …</p>
local
_
シャドウイングは、カーソルの下の変数の宣言や参照をソースコードで強調表示できる優れたIDEでは問題が少なくなります。
ここにちょうど私の2セント…</p>
シャドウ変数は危険すぎて使用できないと思います。
あなたはあなたが望むものは何でも考える権利があります。ただし、データ、調査、または理由さえ提供していないため、その意見には価値がありません。
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
}
それは非常に迷惑な言語になります。