ネイティブ プロパティが Java 7 の一部にならない合理的な理由はありますか?
5 に答える
もちろん、スケジュールとリソースに関連するいくつかの高レベルの理由があります。プロパティを実装し、他の言語機能とのすべての影響と交差を理解することは、さまざまな Java 5 言語の変更のサイズに似た大きなタスクです。
しかし、Sun がプロパティをプッシュしない本当の理由は、クロージャーと同じだと思います。
1) 実装がどのように見えるべきかについてのコンセンサスはありません。むしろ、多くの競合する選択肢があり、プロパティに情熱を傾けている人々は、実装の重要な部分について意見が分かれています。
2) おそらくもっと重要なのは、その機能が本当に必要かどうかについて、コンセンサスが大幅に欠如していることです。多くの人がプロパティを欲しがっていますが、それが必要でも役に立たないとも考えていない人もたくさんいます (特に、サーバーサイドの人々は、swing プログラマーよりも日常生活にとってプロパティがはるかに重要ではないと考えていると思います)。
プロパティ履歴はこちら:
Java でプロパティを「正しく」実行するのは簡単ではありません。Rémi Forax の作業は、これがどのように見えるかを理解し、対処しなければならない多くの「落とし穴」を明らかにする上で特に価値があります。
一方、Java 7 にはすでに時間がかかりすぎています。閉鎖の議論は、サポートの幅広いコンセンサスを持つ機能 (プロパティなど) を開発するために使用できた多くの精神力を浪費する、物議を醸す巨大な気晴らしでした。最終的に、モジュール化への主要な変更を制限する決定が下されました (Project Jigsaw)。言語については「小さな変更」のみが検討されています (Project Coin の下)。
JavaFX には優れたプロパティ サポートがあるため、Sun はプロパティの値を明確に理解し、それらを実装する方法を知っています。しかし、JavaFX の特性に甘んじてしまった開発者は、Java での中途半端な実装に甘んじることはほとんどありません。それらが行う価値がある場合、それらは正しく行う価値があります。
与えられたものはデフォルトで「未完了」であるため、何かが未完了のままであるために特別な理由は必要ありません。むしろ、何かを「未完了」から「計画済み」または「完了」に移行するには、何らかの説得力のある理由が必要です。この言語機能については、まだ十分に説得力のある理由はありません。
どの言語でもプロパティを回避する理由はさらに2つあります。
プロパティはあまりオブジェクト指向ではありません。それらを簡単に記述できるようにすることで、オブジェクトがその内部状態を提供し、呼び出し元がそれを操作するパターンが促進されます。オブジェクトは、より高いレベルのメソッドを提供し、その内部をプライベートに保つ必要があります。次回、面倒なゲッターの実装を行うときは、呼び出し元がデータをどのように処理するか、およびその機能を直接提供できるかどうかを検討してください。
プロパティは、(セッターを介して)可変状態を促進します。これにより、プログラムの並列化が困難になります。コアの数が増えるにつれて、同時推論を容易にするために、オブジェクトを不変にするように努める必要があります。次回、面倒なセッターの実装を行う場合は、セッターを削除してオブジェクトを不変にすることを検討してください。
- 時間が足りない?
- まだ適切に仕様されていませんか?
- Javaの実装が原因でJavaに追加するのは難しいですか?
- 十分に重要ではないと見なされた、つまり、他のことが優先されましたか?