13

クロージャの利点のいくつかを見ることができます。たとえば、既存のライブラリを簡素化し、将来の設計をより簡単かつ効率的にする方法などです。

ただし、提案案（http://www.javac.info/consensus-closures-jsr.html）で言及されている重要なポイントの1つは、セクション2.5のポイントeにあります。

（仕様は言語を改善します）

e） Javaプラットフォームを拡張するための言語設計を置き換える将来のAPI設計を可能にします。

私はこれがどのように当てはまるかを知るのに苦労しています、確かに言語の設計はまさにそれです-言語自体の設計であり、Javaが言語を変更するためのクロージャを使用してあらゆる種類の奇妙なAPIを開かない限りAPIに置き換えることはできません（これが起こるかどうかは非常に疑わしいです。）

誰かがこれに光を当てて、以前は言語の変更が必要だったが、クロージャが追加されたため、もはや言語の変更が不要になった例を提供できますか？

4

2 に答える 2

6

ドラフト提案を読んでいない人のために、同じドキュメントの後半からもう少し詳しく説明します。

クロージャの追加により、Javaプラットフォームの進化が簡素化されます。Sunの公開バグデータベースにある多くの既存の言語RFEは、クロージャを受け取るメソッドのAPIリクエストとしてリターゲットできます。代わりに、ライブラリメソッドを追加することで、追加のステートメントフォームに対する多くの将来のニーズを満たすことができます。

于 2011-01-21T22:47:35.877 に答える
6

APIの設計と言語の機能は、いくつかの点で確実に互換性があります。Javaの同期されたキーワードのようなものを見てください。これはキーワードですが、言語が十分に非冗長である場合は、APIとして実装することもできます。注釈は別の例です。クラス内のすべてのメソッドをトランザクション化する@Statelessアノテーションの逆の方法も、言語キーワードである可能性があります。

特にクロージャを使用すると、「コードのブロック」をメソッドに簡単に渡すことができ、メソッドはそれを使って何かを行うことができます。

大まかな例として、それぞれにaを作成できます。

for_each(myFooList, #(Foo foo) { 
   String something = foo.getBar() + foo.getKaz();
   System.out.println(something);
});

for eachループが言語の構文によって直接サポートされているほど100％クリーンではないかもしれませんが、言語のような拡張機能を誰もが簡単に体験できます。

于 2011-01-21T23:17:31.203 に答える