2009-04-02 8 views
16

なぜnative propertiesがJava 7に含まれないのか合理的な理由はありますか?Java 7にネイティブプロパティが存在しないのはなぜですか?

+3

機能の量によって言語の能力を測定しないでください。プラットフォーム、生態系を考えてみてください... –

+0

それは驚異的なコメントでした。私はC#を学んでいますが、Javaが欠けている多くの機能は、まるでもっと難しい問題を解決するかのように悲鳴を上げません。また、いくつかのメソッドは、メソッドから複数の戻り値を返すような、より複雑なコードに変換できるように見えるものもあります。あるいは悪名高いgotoステートメント。 –

答えて

15

Javaでプロパティを正しく実行することは容易ではありません。 RémiForaxの仕事は、特にこれがどのように見えるかを理解する上で貴重であり、対処しなければならない多くの "問題点"を明らかにしています。

一方、Java 7はすでに長引いています。クロージャーの議論は、幅広く議論の余地があり、広範な支持を得ている(財産のような)機能を開発するために使用された心の力を無駄にしてしまった。結局のところ、モジュール化に対する大きな変更を制限する決定が下されました(Project Jigsaw)。言語には「小さな変化」のみが考慮されています(プロジェクトコインの下)。

JavaFXは美しいプロパティサポートを備えているため、Sunはプロパティの価値を明確に理解しており、実装方法を知っています。しかし、JavaFXのプロパティによって損なわれてきた開発者は、Javaでの半分の実装では解決しにくいです。彼らがやる価値があるなら、彼らは正しいことをする価値があります。

+1

あまり知られていないので、プロパティをJavaで正しく実装することの難しさについて簡単に説明できますか? – Jason

3
  • 時間が足りませんか?
  • まだ間違っていますか?
  • javaの実装のためにjavaに追加するのは難しいですか?
  • 他のものが優先されているとは思われません。
18

もちろんスケジュールやリソースに関連するいくつかの高レベルの理由があります。プロパティの実装と他の言語機能との分岐や交差のすべてを理解することは、さまざまなJava 5言語の変更のサイズに似た大きなタスクです。

しかし、私はSunがプロパティをプッシュされていない本当の理由は、クロージャと同じだと思う:実装がどのように見えるかのコンセンサスはありません)

1。むしろ、多くの競合する選択肢があり、プロパティについて熱心な人々は、実装の重要な部分について意見が異なります。

2)もっと重要なことは、その機能がまったく欲しいかどうかについて合意が欠如していることです。多くの人々がプロパティを必要としている一方で、必要性や有用性はないと思う人が多くいます(特に、サーバーサイドの人々はスイングプログラマよりも日々の生活にとってプロパティがそれほど重要ではないと思います)。ここ

プロパティ歴:

+0

興味深い。私は不動産に関する論争を知りませんでした。少なくとも、憎しみの憎しみの閉鎖が誘発されたわけではありません。賛否両論の背景に記入するためのリンクを提供できますか?私はプロパティがあまり重要ではないサーバーサイドであること、そしてJavaFXがクライアント上の必要性に対処することに同意します。 – erickson

+1

サーバー側の人物であるため、プロパティはすべて私が所有しています。 – trunkc

+0

古いプロパティのディスカッションにリンクが追加されました。個人的に、私は積極的に相反しています。私は提案のほとんどが私をあまりにも興奮させないと思う。私は、JavaがGroovyやScalaのようにこの部門で本当に満足するためにはるかに遠くまで行くことができるとは思っていません。 –

10

どれ与えられたものは、デフォルトでは「行わない」されているので、特別な理由が行われていないままに何かのために必要ありません。むしろ、何かを「未完了」から「計画済み」または「完了済み」に移行させるためには、説得力のある理由が必要です。この言語機能にはまだ十分な理由はありません。

5

任意の言語での特性を回避するために、2つの理由があります。

  • プロパティは、非常にオブジェクト指向ではありません。書きやすいようにすることで、オブジェクトが内部状態を提供し、呼び出し元がそれを操作するパターンを奨励します。オブジェクトは、より高いレベルのメソッドを提供し、内部をプライベートに保つ必要があります。次回は、ゲッターを面倒に実装しているときに、呼び出し元がデータを使って何を処理するのか、そしてその機能を直接提供できるかどうかを検討してください。

  • プロパティは、プログラムを並列化しにくくする(setterを使用して)可変状態を推奨します。コアの数が増えるにつれて、同時の推論を容易にするためにオブジェクトを不変にしようとするべきです。次回は、セッターを退屈に実装しているときに、それを削除してオブジェクトを不変にすることを検討してください。

+1

I object _ "プロパティはあまりオブジェクト指向ではありません" _。また、他のものも行う:データを含むデータ構造であり、フィールドの形で、しばしば属性と呼ばれるデータ構造であり、コードはプロシージャの形で、しばしばメソッドと呼ばれる。 /en.wikipedia.org/wiki/Object-oriented_programming)"._(API/class /)オブジェクトのユーザーに、定義上のものの半分を無視させることは、少なくとも不便です。 'person.name =" Nimoy ";'と 'person.setName(" Nimoy ");と' name = person.name; 'と' name = person.getName();との対比です。 。 –

+0

私は、「あまりオブジェクト指向ではない」というフレーズを避けることを提案しますが(この時点ではほとんど無意味ですが)、両方の点を保持しています。さもなければ、読者はOOPの彼ら自身の個人的な定義に焦点を合わせ、実際にここで言われていることを無視するでしょう。 – tne