Java 또는 C #과 같은 언어의 디자이너가 null 참조의 존재와 관련된 문제를 알고 있다고 확신합니다.

물론이야.

또한 옵션 유형을 구현하는 것은 null 참조보다 훨씬 복잡하지 않습니다.

나는달라고 간청한다! C # 2에서 Null을 허용하는 값 ​​형식으로 들어가는 디자인 고려 사항은 복잡하고 논쟁의 여지가 많았습니다. 그들은 언어와 런타임의 디자인 팀을 수개월 간의 토론, 프로토 타입 구현 등으로 가져 갔으며 실제로 nullable boxing의 의미는 C # 2.0 배송에 매우 가깝게 변경되었으며 이는 매우 논쟁의 여지가 있습니다.

그들은 왜 어쨌든 포함하기로 결정 했습니까?

모든 디자인은 미묘하고 심하게 양립 할 수없는 많은 목표 중에서 선택하는 과정입니다. 고려할 몇 가지 요소에 대한 간단한 스케치 만 제공 할 수 있습니다.

• 언어 기능의 직교성은 일반적으로 좋은 것으로 간주됩니다. C #에는 nullable 값 형식, nullable 값 형식 및 nullable 참조 형식이 있습니다. 널 입력 불가능 참조 유형이 존재하지 않으므로 유형 시스템이 직교하지 않습니다.

• 기존 C, C ++ 및 Java 사용자에게 친숙 함이 중요합니다.

• COM과의 쉬운 상호 운용성이 중요합니다.

• 다른 모든 .NET 언어와의 쉬운 상호 운용성이 중요합니다.

• 데이터베이스와의 쉬운 상호 운용성이 중요합니다.

• 의미론의 일관성이 중요합니다. 우리가 TheKingOfFrance를 null과 동일하게 언급한다면 그것은 항상 “지금은 프랑스의 왕이 없다”는 것을 의미합니까, 또는 “프랑스의 왕이 분명히 있습니다. 또는 “프랑스에서 왕이 있다는 개념은 무의미하므로 질문하지 않아도됩니다!” Null은 C #에서 이러한 모든 것을 의미 할 수 있으며 이러한 모든 개념이 유용합니다.

• 성능 비용이 중요합니다.

• 정적 분석에 적합한 것이 중요합니다.

• 형식 시스템의 일관성이 중요합니다. 우리는 할 수 항상 nullable이 아닌 참조가 없다는 것을 알고 결코 아래에 있는 유효하지 않은 것으로 관찰 상황? null이 아닌 참조 유형의 필드를 가진 객체의 생성자에서는 어떻습니까? 참조를 작성 해야하는 코드에서 예외가 발생 하여 객체가 완성되는 해당 객체의 마무리 장치 는 어떻습니까? 보증에 관한 거짓말 시스템은 위험합니다.

• 그리고 시맨틱의 일관성은 어떻습니까? Null 값은 사용될 때 전파되지만 Null 참조는 사용될 때 예외를 발생시킵니다. 일관성이 없습니다. 그 불일치가 어떤 이점으로 정당화 되었습니까?

• 다른 기능을 중단하지 않고 기능을 구현할 수 있습니까? 이 기능이 배제 할 수있는 다른 기능은 무엇입니까?

• 당신은 당신이 원하는 군대가 아닌, 당신이 가진 군대와 전쟁을합니다. C # 1.0에는 제네릭이 없으므로 Maybe<T>대안으로 말하는 것은 시작이 아닌 완전한 방법입니다. 런타임 팀이 null 참조를 제거하기 위해 제네릭을 추가하는 동안 .NET이 2 년 동안 미끄러 졌어 야합니까?

• 타입 시스템의 일관성은 어떻습니까? Nullable<T>모든 유형의 값에 대해 말할 수 있습니다. 아니, 그건 거짓말입니다. 말할 수 없습니다 Nullable<Nullable<T>>. 할 수 있을까요? 그렇다면 원하는 의미론은 무엇입니까? 이 기능에 대해서만 전체 유형 시스템에 특별한 경우를 두는 것이 가치가 있습니까?

등등. 이러한 결정은 복잡합니다.

답변

file = openfile("joebloggs.txt")

for line in file
{
  print(line)
}