구조적 타이핑의 단점

방금 Daniel Spiewak 가 Scala의 ans Java의 공칭 타이핑 과 비교하여 구조 타이핑 의 장점에 대해 이야기하는 것을 보았습니다 . 이 차이점의 한 가지 예는 다음 Java 코드입니다.

public interface Foo {
  public int length();
}
public interface Bar {
  public int length();
}

Foo f = ...;
Bar b = f;

Foo그리고 사이에 유형 호환성이 있기 때문에 컴파일되지 않을 것 Bar입니다.

반면에 구조적 유형 시스템은 두 유형이 동일하거나 호환 가능하다고 선언 할 수 있으므로 무엇보다도 오리 입력을 확인할 수 있습니다.

이제 구조 유형 시스템의 장점을 대부분 이해한다고 생각하지만 다음과 같은 예제에서 유형 안전을 무효화하지 않을지 궁금합니다.

class Foo {
  class Bar { /* ... */ }
  def takeBar(b: Bar) = { /* ... */ }
  def getBar: Bar = new Bar
}

val foo1 = new Foo
val foo2 = new Foo
foo1.takeBar(foo1.getBar) // should compile
foo1.takeBar(foo2.getBar) // should not compile

구조적 유형 시스템에서 마지막 줄도 컴파일 될 것이며, 그렇다면 유형 안전성과 관련하여 불리한 점이 아님을 이해하고 있습니까?

실제로 경로 종속 유형은 구조적 입력과 명 목적 입력에 직교합니다. 단순한 구조적 유형 언어의 맥락에서 내부 클래스가 무엇을 의미하는지는 분명하지 않습니다. 그러나 이것을 정의하는 것은 매우 가능합니다 . 구조적으로 형식화 된 컨텍스트에서 내부 클래스를 정의하려면 나열된 것과 같은 사례가 거부되도록해야합니다 (스칼라가 거부 한 것과 같은 이유로).

스칼라와 같은 방식으로 경로를 종속 유형을 존재 유형으로 모델링하여 이러한 경우를 거부합니다. 객체 액세스를 둘러싼 동일한 팩 / 풀기 절차가 유지되며 결과는 스칼라와 거의 동일하게 보입니다. 결과는 공칭 유형 평등처럼 보이지만 유형 호환성 문제는 여전히 이름이 아닌 인터페이스에서 결정되므로 구조적 유형 시스템입니다.

구조적 타이핑은 많은 의미를 갖지만, 공칭 유형 시스템에서 우리 모두가 알고 사랑하는 대부분의 동일한 개념이 구조로 이어집니다. 구조적 타이핑은 유형 호환성을 정의하는 다른 방법에 지나지 않습니다.

구조적 타이핑을 사용하면 일반 라이브러리 코드를보다 쉽게 ​​작성할 수 있습니다. Java 생태계가 부풀어 오르는 가장 큰 이유는 작은 라이브러리를 쉽게 작성하기가 어렵 기 때문입니다. Java가 구조적으로 타이핑되면 다른 이야기와 훨씬 더 나은 상황이라고 생각합니다.

구조적 타이핑에 대해 생각할 수있는 유일한 단점은 컴파일 속도가 느려질 수 있다는 것입니다. 구조 언어가 일반적으로 명목 언어보다 느리게 컴파일되는지 확실하지 않지만, 예를 들어 Golang은 구조적으로 형식화되어 컴파일 속도가 매우 빠릅니다.