パッケージが言うように、「comprehension_expression」は「単なる文字列」であると言うのは真実ですが、一方で、ソースコードは単なる文字列です。プログラミング言語は単なる文字列です。
SQL SELECT ステートメント
–これは、「comprehension_expression」の構文と機能のインスピレーションの一部である可能性が非常に高いです(ただし、ドキュメントで言及されていないため、そうであるかどうかは明らかではありません–おそらく、開発者の会話を掘り下げれば、できるかもしれません見つけてください)–</p>
単なる文字列です。
確かにそれらは単なる文字列ですが、解決しようとしている問題に関連する構造があります。問題は、構造が適切に記述されているかどうかです。そのパターン、目前の問題との関係は明確になっていますか? 他の人が設計した他の構造との関係は明らかですか?
「comprehension_expression」は単なる文字列ですが、一方で、その複雑さは、それ自体が一種のサブ言語であることにほとんどなります。
しかし、ドキュメント ( https://docs.angularjs.org/api/ng/directive/ngOptions ) で描かれている方法は、「書式設定された単なる文字列」であるという態度を反映しています。ng-options ディレクティブのタイプとして ng-options のドキュメントに隠されています。ある程度、それ自体は実体ではなく、二級市民です。
さまざまな形式がリストされている方法は、考えられるさまざまな形式に関連するパターンがなく、その場しのぎのような奇妙な感じを与えることがあります (よく見るとパターンはありますが)。規則的な構造を持つ正式な文法がなければ、考えられるすべてのオプションを本当にカバーしているかどうか疑問に思うでしょう。たとえば、SQL SELECT ステートメントの MySQL ドキュメントと比較すると: https://dev.mysql.com/doc/refman/5.7/en/select.html
明らかに、そのような正式な構文は非常に威圧的であり、「comprehension_expression」の場合には必要ないかもしれませんが、一方で、それが正確に定義されていることを知っていると安心できます。
質問者は、ドキュメントで「comprehension_expression」がさりげなく言及されていることに多少不安を感じていたのではないかと思います。簡単に言及されただけで、独自のページなどが与えられていない、一種の浮遊する幽霊のようなエンティティのように見える場合があります.
それ自体がエンティティとして扱われる独自のページを持つことは価値があるかもしれません。なぜなら、それはこの「サブ言語」の設計に関する議論を招くからです。それはどのようにして生まれたのですか?「サブ言語」のさまざまな機能の理由は何ですか? 競合する機能、つまり構文はどれですか? この機能をその機能と一緒に使用できるのに、別の機能を使用できないのはなぜですか? この「サブ言語」の設計において、SQL などからのインスピレーションはありますか?
それ以外の場合は、同種の他の DSL とは関係のない、思いがけない発明のようです。
ng-options に関するブログ投稿で、
https:
//www.undefinednull.com/2014/08/11/a-brief-walk-through-of-the-ng-options-in-angularjs/ Shidhin 氏のリンク先ちょっとした議論
https://groups.google.com/forum/#!topic/angular/4EDe8xIbjLU
この問題だけが議論されている場所。「Matt Hughes」は、「1 つのディレクティブに対して、さらに多くの複雑さが追加されているように見える」という意見も表明しています。
おそらく、これはそれほど大したことではありません。出したかっただけなのに。