問題タブ [syntactic-sugar]

検討：

for each構文を使用しないと、同等のforループはどのようになりますか?

ここにいくつかの宝石があります：

リテラル:

デフォルト:

もちろん、匿名関数は知っていますが、それらをリテラルとして扱い、その場で (クロージャーとして) 実行できることは素晴らしいことです。

質問: javascript で使用できる他の優れた構文糖衣は何ですか?

書く代わりに

のようなものを書きたいと思います

Scala にこの種のシンタックス シュガーのようなものはありますか?

私は最近、Java や C# のような言語で、メソッドのパラメーターの型として「ダック」型を含めることは、構文糖衣の良い形になるだろうかと考えていました。これは次のようになります。

これは、リフレクションを介して doStuff() を呼び出すためのシンタックス シュガーになるか、別の方法で実装される可能性があります。Foo はどのタイプでもかまいません。foo に doStuff() メソッドがない場合、実行時例外がスローされます。要点は、必要なときに、つまりほとんどの場合、事前に指定されたより厳密なインターフェイス パラダイム (パフォーマンス、エラー チェック) の利点が得られるということです。同時に、ダッキング タイピングへのシンプルできれいに見えるバックドアができ、大規模なリファクタリングを行わなくても、初期設計では予期されていなかった変更をきれいに行うことができます。さらに、100% 後方互換性があり、既存の言語構造と完全に調和する可能性があります。これは、API を混乱させ、乱雑にする原因となる過度に設計された場合に備えたプログラミング スタイルを削減するのに役立つと思います。

listsort()メソッドは、を返す修飾子関数ですNone。

したがって、辞書内のすべてのキーを反復処理したい場合は、次のことはできません。

代わりに、私はしなければなりません：

複数のステップに分割することなく、これらのキーをソートされた順序で繰り返すためのきれいな方法はありますか？

たとえば C# のプロパティのシンタックス シュガー:

または単に

Java に逐語的な文字列がありません... "C:\\My Documents\\" ではなく @"C:\My Documents\"

Javaにはもっと「シュガー」が必要だと思いますか? 次のJavaバージョンでシュガーが登場することを知っている人はいますか?

C＃で作業しているときに、このエラーメッセージに遭遇しました

プロパティまたはインデクサーをoutまたはrefパラメーターとして渡すことはできません

私はこれの原因を知っており、正しいタイプのローカル変数を作成し、それをout/refパラメーターとして関数を呼び出してから、プロパティに割り当てるという簡単な解決策を実行しました。

になる

プロパティが現在のコンテキストでの取得と設定をサポートしていない場合、これは明らかに失敗します。

なぜC＃は私のためにそれをしないのですか？

これが問題を引き起こす可能性がある場所を私が考えることができる唯一のケースは次のとおりです。

• 糸脱毛
• 例外

スレッド化の場合、その変換は書き込みが発生するタイミング（関数呼び出し後と関数呼び出し後）に影響しますが、それを信頼するコードは、壊れたときにほとんど共感を得られないのではないかと思います。

例外については、懸念事項は次のとおりです。ref関数がスローよりもいくつかのパラメーターの1つに割り当てるとどうなりますか？些細な解決策では、パラメータのすべてが割り当てられるか、割り当てられない場合があります。繰り返しになりますが、これは言語の使用がサポートされるとは思いません。

注：このエラーメッセージが生成される理由の仕組みを理解しています。私が探しているのは、C＃が簡単な回避策を自動的に実装しない理由です。

シンタクティック シュガー (IMHO) を使用すると、一般に、非常に最小限のプリミティブ セットからコーディングするよりも、プログラムがはるかに読みやすく、理解しやすくなります。良く考え抜かれたシンタックス シュガーのマイナス面はあまり見当たりません。基本的に、構文糖衣はせいぜい不必要であり、最悪の場合は避けるべきものだと考える人がいるのはなぜですか?

編集:名前を付けたくありませんでしたが、人々が尋ねたので、たとえば、ほとんどの C++ および Java プログラマーは、率直に言って、言語の構文糖衣の完全な欠如を気にしていないようです。多くの場合、砂糖の不足をトレードオフに値するほど言語の他の部分が好きであるとは限りません。それは、彼らが本当に気にしないことです. また、Lisp プログラマーは自分たちの言語の奇妙な表記法をほとんど誇りに思っているようですが (技術的にそうではないため、構文とは呼びません)、この場合は、Lisp のメタプログラミング機能を同じくらい強力にすることができるため、より理解しやすいのです。

既存のクラス ライブラリの単純なラッパー クラスをいくつか作成したいと考えています。構文を読みやすく、推測しやすいものにするために (コード補完を介して)、java.lang.Objectのメソッドを削除したいと思います。

問題は、Java のすべての非アトミックなものが Object から継承されるため、これらのメソッドを持つことです。列挙型とインターフェイスを介してラッパー構文を作成しようとしましたが、成功しませんでした。列挙型とインターフェースもjava.lang.Objectsであるためです。

java.lang.Object には、インターフェースのコード補完で見たくない 9 つのメソッドがあります。削除したいもの (赤) と保持したいもの (緑) は次のとおりです。

代替テキスト http://ju.venile.de/upload/java-lang-object-methods.png

以下は、既存のクラスの周りに適切なラッパーを作成するためのサンプル コードです (ビルダー パターン)。

新しいラッパー コードの使用法は次のようになります。

ビルダーのすべてのステートメントをインターフェイスにキャストthisすると、メソッドの可視性が低下します。たとえば、ビルダーが複数のインターフェイスを実装している場合です。残念ながら、すべての java.lang.Object メソッドは残ります。

このメソッドの非表示が Java で可能である場合 (おそらく注釈を使用しますか?)、IDE に依存しない素敵なライブラリを作成できます (どこでも素敵なコード補完)。そうでない場合は、少なくとも Eclipse IDE (おそらくプラグイン) には、java.lang.Object メソッドの非表示を提供できるトリックがあるかもしれません。