2008-04-09

CT中表达式处理的思考

关键字: commontemplate, 表达式

目前的CT中，对于表达式的处理是根据操作符的优先级生成一个二叉树。

有兴趣的朋友可以看看ExpressionReducer.java 这个类。这种处理方式可以说是中缀表达式的方式吧。然后到解释模板内容的时候，再遍历这个二叉树。

 

那么，是不是可以考虑换一种方式呢？也就是后缀表达式的形式。后缀表达式的最终结果就是一个栈的结构，在Java中就好像是一个List。而当对这个表达式进行解释的时候，只需要对栈进行从上到下的访问就可以了。

 

两种方式哪个更好？个人觉得后缀表达式更好一些。原因有以下几点：

1、使用中缀表达式需要生成一个树形结构，而模板本身为了缓存，进行了序列化操作，从序列化的角度来看，一个栈的

   结构应该比一个树的结构要简单。

2、复杂度上。后缀表达式生成的栈要更简单，这样也就让测试变得更容易。而且也更直观。

 

不过我对CT目前仍然不是彻底的了解，或许我的理解有疏漏的地方。这也仅仅是一个想法而已。待更加深入地了解CT后，再回头看看这个想法是否正确吧！

评论
javatar 2008-04-25
你考虑的很对, 当时设计时, 我也考虑过这个问题, 在编译原理中, 通常都会把"中缀表达式"转译成"后缀表达式"进行存储, 因为"后缀表达式"的装配与执行方式都要快, 只需单栈(参数栈)即可完成, 而"中缀表达式"需要双栈(参数栈和操作符栈)配合才能完成.

但表达式的运行时结构用树表式, 是可行的, 这样表达式的运算过程是自关联的, 引擎在运行期不再需要干预.

另外, 当时采用的设计思想是"解释器模式", 自顶向下执行, 这样的最大好处是操作符的可扩展性极强. 如果你想给FreeMarker或Velocity加一个操作符, 那是要伤筋动骨的, 从最底层的BNF定义改起.

倒是可以考虑将CT的编译结果通过"后缀表达式"的方式进行存储, 这样在还原时归约(reduce)效率将提高.
发表评论

您还没有登录，请登录后发表评论

yananay
搜索本博客
我的相册
D35bafa8-5bf0-475f-aa06-16f3080557a1-thumb
tdd
共 3 张
存档
最新评论