虽然从某种意义上说,正如包所说的那样,“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”也表达了“一个指令似乎增加了很多额外的复杂性”的观点。
也许这没什么大不了的。我只是想把它放在那里。