Null-Safe演算子(「Elvis演算子」など)がJava 7の「プロジェクトコイン」の一部として拒否されたのはなぜですか?


10

Java 7の「Project Coin」に提案された機能の1つは「Elvisオペレーター」でした。2009年のJavaOneプレゼンテーションのレポートプロジェクトコインには、そのように説明しました。

このプレゼンテーションで取り上げられている「小さな機能」の1つは、いわゆる「エルビス演算子」です。これは、3項演算子のより簡潔なバージョンです。伝統的なJavaを使用すると、Groovyの一部の機能が欠けていることに気づきました。これは、追加された場合、両方の言語で使用できる1つの演算子になります。「Elvis」演算子は、評価された式がnullのときに使用できるデフォルト値を指定するのに便利です。Groovyの安全なナビゲーション演算子と同様に、これは不要なnullを回避する方法を指定する簡潔な方法です。NullPointerExceptionを回避する方法については、以前ブログで説明しました。

プロジェクトコインの他の側面は最終的に実装されましたが、これは実装されませんでした。含まれる可能性のある候補としてJavaOneで提示されたにもかかわらず、Elvisオペレーターが最終的に拒否されたのはなぜですか?

明確にするために、私はこのオペレーターについて具体的に尋ねています。このオペレーターが当時真剣に検討されていたため、Java 7の「プロジェクトコイン」の一部として拒否された理由についてです。メーリングリストなどで拒否の理由が議論されているのではないかと思いますが、何も見つかりませんでした。Javaのどのバージョンにも含まれていない理由に関するより一般的な情報がある場合、それは許容されますが、好ましくありません。


4
怪しい心?
Ewan

1
正当な値としてのnullの使用をサポートおよび奨励するためである可能性が高く、メソッドを実行する前にオブジェクトのタイプをチェックするため、基本的にOOの原則に反します。
JacquesB 2017年

誰かが決定プロセスの明確な文書(メール、メモ、筆記録)を掘り起こすつもりであるか、決定の直接の参加者でなかった場合を除き、ここで答えを実際に知ることはできません。たとえば、ロバートの答えは推測と一般的な言語設計の考慮事項にすぎず、この演算子を拒否した事実と具体的な理由ではありません。したがって、私はこの質問を意見に基づいて締めくくることに投票します。
2017年

1
@amon:私の回答は投稿の冒頭にある憶測であることを認めました。しかし、とにかく答えを投稿しました。1。魚を与える代わりに、釣り方を教えていること、および2.この投稿は、カードを正しくプレイすれば、密告の標的として使用できます。一般的な分析を提供する回答の背後にあるアイデアは、細かい言語の決定に関する無限の議論を思いとどまらせ、他の人が全体的な問題のより広い見方を理解できるようにすることです。
ロバートハーベイ

@RobertHarvey「言語Xに機能Yがないのはなぜですか」という正規のだましターゲットは便利でしょうが、現在の形式の質問はそれに適していないようです。この一般的な質問をするために編集する場合(?.としてX = Java / Y =を使用)、それは確かに通常の質問としては広すぎますが、良い答えがあります。
2017年

回答:


15

もちろん、この質問をするのに最適な人物は私たちはなく、JCP実行委員会の誰かです。しかし、それは私がいくつかのアイドル投機に従事することを妨げません。

「なぜこの機能が実装されなかったのか」という質問に対する答えは、常にメリットがコストを上回らなかったためです。

Eric Lippert(元C#チームのメンバー)は、製品に機能を持たせるには、その機能は次のようにする必要があると述べています。

  • そもそも考えた
  • 望む
  • 設計
  • 指定
  • 実装された
  • テスト済み
  • 文書化
  • 顧客に出荷

言い換えれば、新しいプログラミング言語の機能を実現する前に、多くの重要なことを実行する必要があります。コストはあなたが思っているよりも大きいです。

C#チームでは、すべての新機能のリクエストはマイナス100のスコアで始まります。次に、チームはメリットとコストを評価し、メリットのポイントを追加し、コストのポイントを差し引きます。スコアがゼロを超えない場合、提案された機能は即座に破棄されます。言い換えれば、新機能は説得力のある利点を提供する必要があります。

しかし、ElvisオペレーターはそれをC#にしました。では、なぜJavaにならないのでしょうか。

それらの明らかな類似性にもかかわらず、JavaとC#の言語哲学は大きく異なります。 これは、Javaエンタープライズプログラムがアーキテクチャの大規模で構造的なコレクションである傾向があるという事実によって証明されます。簡潔さと言語表現力は、儀式の祭壇とコーディングの容易さで犠牲にされています。言語の利便性よりも、開発チームの全員が認識できる、よく知られたソフトウェアアーキテクチャパターンの方が適しています。

このReddit交換を検討してください:

Elvisオペレーターは、Javaのすべてのバージョンで7以降に提案されており、毎回拒否されています。異なる言語は、「純粋」から「プラグマティック」までの範囲に沿って異なるポイントに分類され、Elvisオペレーターを実装する言語は、Javaよりも実際のスペクトルの端に向かっている傾向があります。

15年以上のJavaプロのチームが、高度に分散された並行処理のある種類のバックエンド処理システムを作成している場合は、おそらくかなり厳密なアーキテクチャが必要です。

ただし、ジュニアからミドルレベルのチームがいて、その半分がVisual Basicから移行していて、ほとんどがCRUD操作を実行するだけのASP.NET Webアプリを作成している場合... AbstractFactoryFactory抽象離れますが、列は、あなたが使用する必要があることくだらないレガシーデータベースでNULL値可能である制御することはできませんという事実にクラス。

言語哲学におけるこれらの深遠な違いは、言語が使用される方法だけでなく、言語設計プロセス自体が行われる方法にも及びます。C#は慈悲深い独裁者言語です。 C#に新機能を導入するには、実際に1人の人、Anders Hejlsbergを説得するだけです。

Javaはより保守的なアプローチを採用しています。新機能をJavaに導入するには、Oracle、IBM、HP、富士通、Red Hatなどの大手ベンダーのコンソーシアムから合意を得る必要があります。明らかに、そのプロセスは遅くなり、新しい言語機能の基準が高くなります。

「なぜx機能が実装されなかったのか...」という質問には、常に「暗黙のうちに...良いアイデアだとしたら?」という言葉が暗黙的に含まれています。ここで十分に説明したように、選択はそれほど単純ではありません。


8
sarcasm:AbstractFactoryFactoryクラスは、アーキテクチャの厳密さを示す優れた指標であり、コードの肥大化ではありません。/皮肉。
マチャド

2
@RobertHarvey Java言語の設計における委員会の役割についてのあなたの結論は、あまりにも単純すぎます。確かにコミュニティや業界のパートナーとのコラボレーションがありますが、Java言語が「委員会による設計」であるという声明はかなり完全に正しくなく、このポスターの質問に対する恐ろしい(悲しいことに、表面的には信じられる)説明です。
Brian Goetz 2017年

5
あなたが挙げた以前の理由のほとんど-すべての言語機能は誰もが思っているよりも大きく、限られた予算(努力、変更、複雑さ)-は正確です。また、機能Xは使用しません。他の機能YおよびZの方が良い選択だと考えているためです。さらに、他の言語よりも保守的なアプローチを採用しています。これは、各機能が将来的に他の可能な機能と相互作用するか、場合によっては取り消されることがわかっているためです。私たちはJavaを20年間活気があり、関連性のある状態に保ちたいと考えています。これは必然的に、今はクールに見えるすべての機能を詰め込まないことを意味します。
Brian Goetz 2017年

1
@BrianGoetz:問題は「委員会による設計」という言葉の軽蔑的な性質のように思われるため(私は他の方法でJavaを非難しなかったことに気付くでしょう)、この言葉を削除するために私の答えを少し変更しました。
ロバートハーベイ

1
以前は、C#とJavaのデザイナーの間でいくつかのライバル関係がありました。C#は、Javaデザイナによって偽造品と見なされていました(そうです)。C#デリゲートは「オブジェクト指向ではない」という理由で拒否されましたが、実際の理由は、C#に最初に登場したためです。一部の機能が追加または除外されたのは合理的な理由のみであると考えるのは良いことです...私はそれを疑っています。
フランクヒルマン、2017年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.