论面向组合子程序设计方法 之 微步毂纹生

我说taowen，解释一下啦。你不会以为我一看你这么长的xml就明白它是什么了吧？

此外，log4j可以做到针对某个类层次输出某个级别的日志信息这件事情，至少比现在CO的那个要强上那么一点点。或者说，CO怎么能够做到对于org.charon下面的DEBUG以上的信息，输出到charon_debug.log，而对于org.charon下的WARN以上的信息，输出到charon_warn.log, 也许，同时又会对 org.ajoo做一些类似的设置。

要做到这点，其实不难的。而且也不用动组合子。

只要做一个工厂，抽象还是静态随便。或者甚至可以用ioc从容器注射

Logger getLogger(Class c);;

然后根据这个类c的package来决定log文件名字就是了。

我的项目因为没有这个需求，自然没扯上这个。而且这个也用不上组合子。

其实这些问题的核心就是一个，最初的combinator应该如何设定，或者是你的那个0和1是怎么来的，你怎么知道就需要0和1，你怎么判断－1就没有必要。

不过确实oo在简单场景下的灵活应用是不足的。这一点说的很准确。但是如何保证oo所处的环境在不断的向复杂化发展之后，还可以复用原来的工作和经验呢？

这个嘛。我的水平不够，理论上的原因说不清楚。就知道0在整个数论系统里面就是比-1重要的多。而很多的公理系统，组合子系统都共享这种同样的性质，就是：0,1,2,然后所有其它的。




可以的。不管你的系统多复杂，也能重用+-*/这些基本的组合子把？为什么？因为它们足够简单。更何况，如果你的组合子足够简单，那么本身就没花多少工作量，就算有几个如firebody所说，不能重用，又如何？

反过来 呢？  脱离了需求，你怎么知道你推导的组合子够用了呢？ 估计更多的情况时还得回到需求再根据需求推导一遍。

说实在话，虽然ajoo提到CO看起来很美丽，但是脱离了需求的设计也是足够“恐怖“的。 而且，即使像ajoo所说，如果你的CO足够“原子“ 或者“简单“，那么你的CO能够被复用的概率就越大（这句话是我设想的） ，那么，看起来，这些COs应该以一种颇为精妙的搭建思路 搭建起来，以应付更多更复杂的需求了。 那么，搭建COs的思路似乎也是一个设计瓶颈所在，这个瓶颈再没有需求的检验下，似乎冒的风险很大，而且，因为这个瓶颈是整个COS发挥 “作者一相情愿的足够强大的组和能力“的构建基础，这意味着对它的任何改动都会带来不可估量的影响。

按照这样的分析下来，似乎，越复杂的系统，CO的设计并没有足够的能力将复杂的系统 抽丝剥简 般 分离出足够简单的CO组合来。

我分明的看到有人在打马虎眼，不过也无妨，瑕不掩瑜嘛。这个用java的确有些力不从心的感觉。

只是你的估计。不要小看组合产生的几何级数增长的变化能力。偶尔确实会有要回头增加组合子的需要，尤其是开始的时候。但是增加那么几行简单的不能再简单的代码真的很麻烦吗？

用c++就是自虐了。

我用c++玩过smonde的，你要是有工夫，去研究研究。比在这看不懂瞎起哄强。

ajoo，我只是觉得不应该忽视细节，程序员在乎细节比在乎理论重要，不要一说起来就要吵架的架势。其他的就不说了。