回波总为什么我不赞同你关于ANTLR不适合模板引擎的意见
波总好,
在谈谈我对 JFinal Marketing 的一些看法那篇博文的评论中 我们谈论到了 ANTLR, 这里继续和波总谈谈在技术上我对这方面的理解.
先说下 ANTLR 到底什么. ANTLR 官网给自己的定义是:
ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files. It"s widely used to build languages, tools, and frameworks. From a grammar, ANTLR generates a parser that can build and walk parse trees.
简单地说 ANTLR 是一个词法语法分析工具, 它不是一个应用层面的库, 也不是为应用程序开发使用的. ANTLR 的用户是需要定义某种语法, 并实现对该语法文件的解析的库开发者. 对 ANTLR 的应用场景在这篇文章中有更多的介绍.
下面列举几个使用 ANTLR 的项目:
- Groovy - 解析 Groovy 源文件并生成 AST
- Cassandra - CQL 语法解析和词法分析
- Salesforce APEX - APEX 脚本解析器
- Twitter - 查询语言语法分析
- StringTemplate - 模板引擎语法分析
- Beetl - 模板引擎语法分析
波总在上篇博文评论中谈到:
antrl 会为你生成一个人类根本无法阅读的 parser,这个对于细致打磨是很有害的,因为你根本无法调试这个 parser,出了问题你也无法追踪。
所以波总认为:
我仅仅只是认为 antrl 用于模板引擎并不是个好主意,不是最好的方案,enjoy 的方案更好。 我从头到底都没否定过 antrl 用于别的领域,也没有说 antrl 有任何不好。
这个地方我觉得有点奇怪了, 使用 ANTLR 的直接结果就是生成 Parser, 不仅仅对模板引擎如此, 在所有使用场景下都是一样的. 如果因为"生成了一个人类无法阅读的 parser" 就否定 ANTLR 在模板引擎的应用, 那是不是也应该否定 ANTLR 在包括 Groovy 在内的其他项目中的使用呢? 因为他们也会毫无疑问使用 ANTLR 生成 Parser, 不是吗? 更有趣的是 ANTLR 的作者还专门使用了 ANTLR 开发了模板引擎 StringTemplate 作为 ANTLR 的 showcase, 难道他没有遇到这个 "生成一个人类根本无法阅读的 parser" 的问题, 所以不知道 ANTLR 用于模板引擎并不是个好主意吗?
在这里我的看法是 ANTLR 的生成结果 - 一个 "人类根本无法阅读的" Parser, 根本就不是拿来给人读的, 也不是用来让人直接"细致打磨"的, 从 StringTemplate, 到 twiter query language, 再到庞大复杂的 Groovy, 都不会有人在 ANTLR 的生成结果上做修改打磨, 就像没有人在 Javac 编译之后的字节码文件上做修改打磨一样, 这个 Parser 是一个中间结果, 对于这个中间结果的细致打磨当然应该回到 g 语法文件; 这个道理和 .class 文件中有问题应该回到原始的 .java 源代码去修改一样, 没有人会试图去"打磨"生成的 class 字节码, 对吗?
我并不是 ANTLR 专家, 连用户都算不上. 以上理解很可能有不足之处, 欢迎波总和使用过 ANTLR 的专业同行批评指正.
以上是 回波总为什么我不赞同你关于ANTLR不适合模板引擎的意见 的全部内容, 来源链接: utcz.com/z/511932.html