这经常出现:您的应用程序已经变得足够广泛,是时候在其中添加一些可编程性以使其灵活了。一个示例可能是财务应用程序 - 您想添加一个公式编辑器,以便您可以创建自己的自定义公式,而无需重新编译代码。
您必须做出选择:您是否创建自己的标记器、解析器和解释器/编译器链,这可能需要很长时间并且可能会不正确?还是您只是嵌入了另一种脚本语言,它的问题是它可能会使您的代码膨胀并使您的应用程序暴露于安全漏洞。
您将如何权衡取舍并做出此决定?
这经常出现:您的应用程序已经变得足够广泛,是时候在其中添加一些可编程性以使其灵活了。一个示例可能是财务应用程序 - 您想添加一个公式编辑器,以便您可以创建自己的自定义公式,而无需重新编译代码。
您必须做出选择:您是否创建自己的标记器、解析器和解释器/编译器链,这可能需要很长时间并且可能会不正确?还是您只是嵌入了另一种脚本语言,它的问题是它可能会使您的代码膨胀并使您的应用程序暴露于安全漏洞。
您将如何权衡取舍并做出此决定?
没有折衷——嵌入一个经过全面测试、有据可查的解释器。否则,你最终会得到像 MAXScript 这样的可憎之物。
插件系统怎么样?有几个优点:
除非 DSL 足够简单以至于解析器/解释器适合单个页面,否则我建议嵌入现有的脚本语言。
我最近花了几个月的时间在我继承的一个项目上工作,该项目包含一种完全本土的脚本语言。我花了很多时间来理解解析器和解释器,这样我就可以修复错误,使其线程安全,扩展它,优化它。此外,还有时间学习和理解这种新脚本语言的怪癖,它与我已经知道的其他语言几乎一样但又不完全一样。我宁愿利用这段时间嵌入现有的语言,如 Ruby 或 Lua,并对其进行调整以适应我们的需求。
用户将受益于一种更易于编程、怪癖和陷阱更少的语言。我会从对精心设计和流行语言的内部结构的更深入了解中受益,而不是在“myScript”中获得相对毫无价值的专业知识。
我会使用现有的解析器生成器(如 ANTLR 或 Haskell/Scala 的解析器组合器)创建自己的解释器。这真的没有那么难,而且对于简单的语言来说,这真的很容易。我在一个下午创建了一个极其简单的 DSL 的实现,它第一次运行完美(没有错误)。
话虽如此,您不必设计自己的图灵完备语言。如果您的需求如此复杂,您可能应该嵌入脚本语言。如果你在 JVM 上,JRuby 和 Clojure 是这类事情的优秀候选者,特别是考虑到它们在内部 DSL 领域的优势。