Null 안전 연산자 (예 : "Elvis 연산자")가 Java 7의 "프로젝트 코인"의 일부로 거부 된 이유는 무엇입니까?

Java 7의 "Project Coin"에 제안 된 기능 중 하나는 "Elvis operator"입니다. 2009 자바 원 프리젠 테이션의 보고서 프로젝트 동전에 같은 묘사 :

이 프레젠테이션에서 다루는 "작은 기능"중 하나는 소위 "엘비스 연산자"인데, 이는보다 간결한 3 진 연산자 버전입니다. 전통적인 Java를 사용할 때 Groovy의 일부 기능이 누락되어 있으며 두 언어 모두 추가 된 경우 사용할 수있는 연산자입니다. "Elvis"연산자는 평가 된식이 null 일 때 사용할 수있는 기본값을 지정하는 데 편리합니다. Groovy의 안전한 탐색 연산자와 마찬가지로 불필요한 null을 피하는 방법을 지정하는 간결한 방법입니다. 이전에 NullPointerException을 피하는 방법에 대해 블로그했습니다.

Project Coin의 다른 측면은 궁극적으로 구현되었지만 이것은 아닙니다. Javavis에서 포함 후보로 제시 되었음에도 불구하고 Elvis Operator가 궁극적으로 거부 된 이유는 무엇입니까?

분명히, 나는이 연산자에 대해 구체적으로 묻고 있으며, 당시 심각하게 고려되었다는 점을 감안할 때 Java 7의 "프로젝트 코인"의 일부로 거부 된 이유입니다. 메일 링리스트 또는 거부 이유가 논의 된 곳이 있다고 생각하지만 아무것도 찾을 수 없습니다. Java 버전에 포함되지 않은 이유에 대한 일반적인 정보가있는 경우 이는 허용되지만 바람직하지 않습니다.

java api-design

— 썬더 포지
소스

수상한 마음?

— Ewan

그것은 null을 합법적 값으로 사용하도록 지원하고 장려하기 때문에 가능성이 높으며 메소드를 실행하기 전에 객체 유형을 확인하기 때문에 기본적으로 OO 원칙에 반합니다.

— JacquesB

누군가가 의사 결정 과정에 대한 명시적인 문서 (이메일, 메모, 대화 내용)를 파거나 의사 결정에 직접 참여하지 않는 한, 여기서 답을 알 수 없습니다. 예를 들어 Robert의 대답은 추측과 일반적인 언어 설계 고려 사항 일 뿐이며이 연산자를 거부 한 사실적이고 구체적인 이유는 아닙니다. 그러므로 나는이 질문을 의견에 근거하여 종결하기로 투표하고 있습니다.

— amon

@ amon : 나는 내 게시물의 시작 부분에 내 대답이 추측임을 자유롭게 인정했다. 그러나 나는 어쨌든 대답을 게시했다. 1. 나는 물고기를주는 대신 낚시하는 법을 가르치고있다. 일반적인 분석을 제공하는 답변 뒤에 숨겨진 아이디어는 미세한 언어 결정에 대한 끝없는 논쟁을 피하고 다른 사람들이 전반적인 문제에 대한 더 넓은 견해를 볼 수 있도록 돕는 것입니다.

— Robert Harvey

@RobertHarvey“언어 X에 Y 기능이없는 이유”정식 속임수 목표는 편리하지만 현재 형식의 질문은 적합하지 않은 것 같습니다. 이 일반적인 질문을하기 위해 (X = Java / Y = ?.를 예로 사용하여 ) 편집해야한다면 확실히 일반적인 질문만큼 광범위 할 것입니다.하지만 좋은 대답이 될 것입니다.

— amon

당연히이 질문을하는 가장 좋은 사람은 우리가 아닌 JCP 집행위원회의 누군가입니다 . 그러나 이것이 유휴 추측에 관여하는 것을 방해하지는 않습니다.

모든 "이 기능이 구현되지 않은 이유"질문에 대한 답변은 항상 혜택이 비용을 초과하지 않았기 때문입니다.

Eric Lippert (이전의 C # 팀원)는 제품에 기능이 있으려면 해당 기능이 다음과 같아야합니다.

처음에 생각
원하는
설계
지정된
구현
테스트
문서화
고객에게 배송

다시 말해서, 새로운 프로그래밍 언어 기능을 실현하기 위해서는 반드시해야 할 중요한 일이 많이 있어야합니다. 생각보다 비용이 큽니다.

C # 팀에서 모든 새로운 기능 요청은 점수 -100으로 시작합니다. 그런 다음 팀은 혜택 및 비용을 평가하고 혜택에 대한 포인트를 추가하며 비용에 대한 포인트를 뺍니다. 점수가 0을 초과하지 않으면 제안 된 기능이 요약됩니다. 다시 말해, 새로운 기능은 강력한 이점을 제공해야합니다.

그러나 Elvis Operator 는 C #으로 만들었습니다. 왜 Java로 만들지 않았습니까?

명백한 유사성에도 불구하고 Java와 C #은 언어 철학이 크게 다릅니다. 이는 Java 엔터프라이즈 프로그램이 대규모의 구조적 아키텍처 콜렉션 인 경향이 있다는 사실에 의해 입증됩니다. 의식의 제단과 코딩의 용이성에서 간결함과 언어 표현력이 희생됩니다. 개발 팀의 모든 사람이 인식 할 수있는 잘 알려진 소프트웨어 아키텍처 패턴은 언어 편의보다 선호됩니다.

이 Reddit 교환을 고려하십시오 .

Elvis 연산자는 7 이후 모든 Java 버전에 대해 제안되었으며 매번 거부되었습니다. "순수"에서 "실용"에 이르기까지 다른 언어는 스펙트럼을 따라 다른 지점에 속하며, 엘비스 연산자를 구현하는 언어는 Java보다 스펙트럼의 실제적인 끝을 향한 경향이 있습니다.

15 년 이상 Java 전문가로 구성된 팀이 일종의 고도로 분산 된 동시 백엔드 처리 시스템을 작성하는 경우 상당한 수준의 아키텍처를 원할 것입니다.

그러나 중급 팀과 중급 팀 중 절반이 Visual Basic에서 마이그레이션했으며 CRUD 작업을 주로 수행하는 ASP.NET 웹 응용 프로그램을 작성하는 경우 무리를 디자인하는 것이 과도 할 수 있습니다. 의 AbstractFactoryFactory추상적 멀리 당신이 열을 사용해야하는 형편 레거시 데이터베이스에 Null 허용되는 통제 할 수 없다는 사실에 클래스.

언어 철학의 이러한 중대한 차이점은 언어가 사용되는 방식뿐만 아니라 언어 설계 프로세스 자체가 수행되는 방식까지 확장됩니다. C #은 자비로운 독재자 언어입니다. C #에 새로운 기능을 사용하려면 Anders Hejlsberg 한 사람 만 설득해야합니다 .

자바는보다 보수적 인 접근 방식을 취합니다. Java에 새로운 기능을 제공하려면 Oracle, IBM, HP, Fujitsu & Red Hat과 같은 대규모 공급 업체 컨소시엄에서 합의를 얻어야합니다. 분명히 그 과정은 느리고 새로운 언어 기능에 대한 더 높은 기준을 제시 할 것입니다.

"x 기능이 구현되지 않은 이유는 ..."이라는 질문에는 항상 "... 그렇게 좋은 아이디어라면"이라는 단어가 암시 적으로 포함됩니다. 여기서 충분히 설명했듯이, 선택은 결코 간단하지 않습니다.

— 로버트 하비
소스

sarcasm : AbstractFactoryFactory 클래스는 코드 팽만감이 아니라 아키텍처 엄격함을 나타내는 훌륭한 지표이기 때문입니다. /풍자.

— Machado

@RobertHarvey Java 언어 디자인에서위원회의 역할에 대한 결론은 너무 단순합니다. 실제로 커뮤니티 및 업계 파트너와의 협력이 있지만 Java 언어가 "위원회에서 설계"되었다는 진술은 완전히 잘못되었으며이 포스터의 질문에 대한 끔찍한 (표면적으로도 믿을 만하지 만) 설명입니다.

— Brian Goetz

앞서 언급 한 대부분의 이유는 모든 언어 기능이 다른 사람의 생각보다 크며, 한정된 예산 (노력, 변경, 복잡성)은 정확합니다. 우리는 다른 기능 Y와 Z가 더 나은 선택이라고 생각하기 때문에 X 기능을하지 않습니다. 또한 각 기능이 향후 다른 가능한 기능과 상호 작용하거나 일부 경우에는 다른 기능과 상호 작용한다는 것을 알고 있기 때문에 다른 언어보다 더 보수적 인 접근 방식을 취합니다. 우리는 Java가 20 년 동안 활기차고 관련성을 유지하기를 원합니다. 이는 현재 멋진 것처럼 보일 수있는 모든 기능에 영향을 미치지는 않습니다.

— Brian Goetz

@BrianGoetz : 문제는 "커뮤니티 별 디자인"이라는 용어의 중대한 특성 인 것으로 보이므로 (다른 방법으로 Java를 비방하지 않았 음을 알 수 있습니다) 용어를 제거하기 위해 답변을 약간 변경했습니다.

— Robert Harvey

이전에는 C #과 Java 디자이너 사이에 경쟁 관계가있었습니다. C #은 Java 디자이너들에 의해 찢어짐으로 간주되었습니다. C # 델리게이트는 "객체 지향적이지 않다"고 거부되었지만 실제 이유는 C #에서 처음 등장했기 때문입니다. 일부 기능이 추가되거나 제외되는 합리적인 이유 일 뿐이라고 생각하는 것이 좋습니다 ... 의심합니다.

— Frank Hileman