問題タブ [syntactic-sugar]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
29 に答える
2785260 参照

java - Javaの「for each」ループはどのように機能しますか?

検討:

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

0 投票する
30 に答える
13551 参照

javascript - 最高の JavaScript シンタックス シュガー

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

リテラル:

デフォルト:

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

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

0 投票する
2 に答える
423 参照

scala - Scalaの無名関数内で値をバインドするための構文糖衣はありますか?

書く代わりに

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

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

0 投票する
3 に答える
781 参照

refactoring - リフレクションのシンタックス シュガーとしてのダック タイプ: 良いアイデアか悪いアイデアか?

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

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

0 投票する
3 に答える
6935 参照

python - 辞書からキーのリストをソートされた順序で取得する「ワンライナー」の方法はありますか?

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

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

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

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

0 投票する
15 に答える
4774 参照

java - Java にもっとシンタックス シュガーが欲しい!

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

または単に

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

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

0 投票する
4 に答える
678 参照

c# - withキーワードが(C#の場合)悪い場合、これは良い代替手段ですか?


0 投票する
9 に答える
37410 参照

c# - C#プロパティとrefパラメーター、なぜ砂糖がないのですか?

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

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

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

になる

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

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


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

  • 糸脱毛
  • 例外

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

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


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

0 投票する
11 に答える
7075 参照

language-design - シンタクティック シュガーが時々悪いことと見なされるのはなぜですか?

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

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