스칼라가 왜 그림자 변수를 지원합니까?

Question

쉐도우 변수가 너무 위험하기 때문에 사용하는 것이 좋습니다. 스칼라가 왜이 언어 구조를 지원합니까? 거기에 대한 몇 가지 강력한 이유가 있어야하지만, 나는 그것을 찾을 수 없습니다.

Answer 1

변수, 메서드 또는 형식이 그림자 다른 변수, 메서드 또는 내부 범위에서 선언 될 때 같은 이름의 형식이라고되어 ​​있기 때문에 외부를 참조 할 수 없습니다 -scope 엔티티를 정규화되지 않은 방식으로 (때로는 전혀) 사용하지 마십시오. Java와 마찬가지로 Scala는 섀도 잉을 허용합니다.

내가 볼 수있는 한 가지 가능한 이유는 스칼라에서 중첩 된 스코프가 많고 (Java 또는 C++과 비교하여) 상대적으로 짧기 때문입니다. 실제로 블럭은 표현이 예상되는 곳 어디에서도 시작할 수 있으므로 새로운 범위를 시작합니다. 따라서 내부 범위에서 섀도 잉 이름을 사용하면 평균적으로 선언에 가까워지고 모호하지 않게됩니다.

또한 인라인 클로저는 프로그래머가 이미 혼잡 한 범위에서 새로운 변수 이름을 필요로하는 경우가 있습니다. 섀도 잉을 허용하면 다른 이상한 이름을 발명하는 대신에 이미 사용 된 이름과 동일하더라도 충분히 유용한 설명이 포함 된 이름을 계속 사용할 수 있습니다 (예 : my, local, 또는 더 나쁜 경우 _ 또는 단일 - 레터 이름 ...

섀도 잉은 좋은 IDE의 경우 문제가되지 않으며 소스 코드에서 커서 아래의 변수 선언 및 참조를 강조 표시하십시오.

여기 그냥 내 두 센트 ...

Answer 2

나는 그림자 변수를 사용하기에 너무 위험하다고 생각합니다.

귀하는 원하는 것을 생각할 권리가 있습니다. 그러나 데이터, 연구 또는 이유를 제공하지 않았으므로 그 의견은 가치가 없습니다.

왜 스칼라가이 언어 구조를 지원합니까?

유용하기 때문에. 프로그래머는 범위 내의 일부 식별자가 이미 그것을 사용하고 있기 때문에 임의의 식별자 이름을 만들 필요가 없습니다.

와일드 카드 가져 오기가 더 유용합니다. 이는 제 3자가 사용중인 식별자를 추가했기 때문에 컴파일이 중단 될 가능성을 제거하기 때문입니다.

그럴만한 이유가 있지만 그럴 수는 없습니다.

왜 그럴만한 이유가 있습니까? 거기에 장점이 있으며, 단점이 없다면 (아무도 제시하지 않았습니다.) 충분합니다. 단점에 대한 답변에서

편집

내가 그 그림자의 특별한 경우라고해야 설명했다. 그림자는 또한 import 문 또는 중첩 된 package 문을 통해 가져 오는 모든 항목과 동일한 패키지에있는 모든 항목에 영향을줍니다.

는 이제 몇 가지 예를 보자 : 매우 성가신 언어로 만들 것

// Not allowed, because it shadows List 
import java.util._ 

class A { 
    // Not allowed, because it shadows this, hashCode, equals, toString 
    class B 
} 

합니다.