|
锁定老帖子 主题：失踪的链环
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-10-10
honestkent 写道 actionA: condtion1->action1
actionB: condtion2->action2 执行方式为 exclusive(actionA,actionB) 或者 list(actionA,actionB) 等等其他 消息分派并没有解决执行方式的问题，也就是执行规则list exclusive并不属于消息分派解决的问题域？ 执行规则不会超出逻辑运算的闭包， 跟解释逻辑表达式树执行方式一致，应该可以统一出搞一个东西 另外Trustno1能不能讲讲FP的错误处理都是怎么做的？ 尤其是错误处理非常复杂的地方 这只是两种不同的方式把,去超市买东西，有些人喜欢精打细算每拿一个东西就算算总价看看够不够钱，有些人则不管3721直接往购物车里扔东西，到了柜台收银员算总价的时候才发现钱不够然后再丢掉一点无关紧要的东西. Ajoo以前的CO就是第一种方式，我举的例子属于后面一种方式. 其实消息分派有不同的方式和方法,你当然可以手工写分派表像ifelse那样，也可以用Vector(functor,Action)来构造表,但是很多时候你要搞出表中表就会比较麻烦.搞表中表就要像Ajoo那样用Co,用最基本的逻辑组建组合出一张表.其实这些问题到最后就是归结为你如何去构造分派表的问题的.分派表的复杂程度不同，自然也就要使用不同的构造方式. |
| 返回顶楼 | |
|
发表时间：2006-10-10
Trustno1 写道 这只是两种不同的方式把,去超市买东西，有些人喜欢精打细算每拿一个东西就算算总价看看够不够钱，有些人则不管3721直接往购物车里扔东西，到了柜台收银员算总价的时候才发现钱不够然后再丢掉一点无关紧要的东西. Ajoo以前的CO就是第一种方式，我举的例子属于后面一种方式. 其实消息分派有不同的方式和方法,你当然可以手工写分派表像ifelse那样，也可以用Vector(functor,Action)来构造表,但是很多时候你要搞出表中表就会比较麻烦.搞表中表就要像Ajoo那样用Co,用最基本的逻辑组建组合出一张表.其实这些问题到最后就是归结为你如何去构造分派表的问题的.分派表的复杂程度不同，自然也就要使用不同的构造方式. 手工ifelse简单的可行， 复杂点的就挂了。还是构造分派表比较合适 粗想了一下， 不知道对不对。 如果问题域足够复杂，分派表的构造可能要上升到关系模型理论上去， 为了防止分派表过大可能要拆分为几个分派表，来个几级决定分派等等。 如果表中表就类似于对象数据库，不搞就类似于关系型数据库，这两种方式好像能将关系数据库跟对象数据库比较相互优劣的相同结论。 面向对象的程序员可能更习惯于表中表， 数学理论雄厚的人可能关系模型方式更适合 再则就上升到构造什么样子的分派表示模型上去了，可能有比关系模型跟对象模型更合适的分派模型 
|
| 返回顶楼 | |
|
发表时间：2006-10-10
跑个题：大多数的规则s都可以认为能够组织成树的吧。
现在我还没想到哪种规则s必须组织成图的，谁给个必须组织成图的规则s，让我好好思考处理图型规则s的方法。 |
| 返回顶楼 | |
|
发表时间：2006-10-10
ddd 写道 跑个题：大多数的规则s都可以认为能够组织成树的吧。
现在我还没想到哪种规则s必须组织成图的，谁给个必须组织成图的规则s，让我好好思考处理图型规则s的方法。 A&&(B&&D||C&&D)是树，A&&(B||C)&&D就是图,表达的是一个事情。自己想事情套这里面造吧 |
| 返回顶楼 | |
|
发表时间：2006-10-10
我要的不是式子，而是现实中的东西，我的难处就是想不出来可以套这个式子的现实例子。
你说反了。 |
| 返回顶楼 | |
|
发表时间：2006-10-10
N个条件中满足M个即可，这似乎就是图型。
如果枚举的话，一堆式子出来了。 不过这是个true/false问题，实际问题不光是true/false问题。 肯定可以用图来解决任何规则，和语言恐怕都没什么关系。 后加的：图中元素在解决规则问题的时候应该可以复制成另外一个元素，那么可以归结成树，组合模式的经典应用嘛。 所以解决这个什么金卡问题直接上组合模式。 |
| 返回顶楼 | |
|
发表时间：2006-10-10
组合模式（或者进一步，ajoo提出的CO）只是把 if, else 向上移动。
If, Loop 做成 API (class, method)，和做成 DSL (keyword)效果是一样的。 从这个角度来说，ErLang 的 pattern match 接近于 DSL，已经达到了类似的效果。 CO重用的对象有两类， 一种是组合子本身。这个好说，用不用组合子，都很容易做到，一般的 lib, module 都行。 一种是ajoo提到的higher order logic. 就是组合子之间的关系，比如， and, or, if, loop,seq (类似于workflow？)。这个是CO特有的重用。 但是，在业务复杂的时候，这两者的重用度都不高。这可能就是为啥人们倾向于用DSL的原因——既然没啥可以重用的，我就尽量把逻辑组合向上提，然后用高阶script DSL 重写一份。 |
| 返回顶楼 | |
|
发表时间：2006-10-10
后面越说越远了，javaeye的帖子似乎总也跑出这种怪圈
另外，发现自己老了，对这也的帖子现在没有当年的热情了。 |
| 返回顶楼 | |
|
发表时间：2006-10-10
树的组织数据的方法和语言无关，计算最后的discount自然会出现if else，但方法之优雅恐怕不是什么消息分派这些解决方法能达到的。
erlang看不懂，python那段如果碰上复杂规则恐怕描述都会出问题，整个就是个枚举规则。 举个例子：4项（a1,a2,a3,a4）满足两项=50就加10 discount_rules=[(lambda member:member.a1==50 and member.a2==50,discount_add10), (lambda member:member.a1==50 and member.a3==50,discount_add10), (lambda member:member.a1==50 and member.a4==50,discount_add10), (lambda member:member.a2==50 and member.a3==50,discount_add10), ... ] 只要出现交叉条件，枚举性描述必然会混乱不堪。 |
| 返回顶楼 | |
|
发表时间：2006-10-10
ddd 写道 树的组织数据的方法和语言无关，计算最后的discount自然会出现if else，但方法之优雅恐怕不是什么消息分派这些解决方法能达到的。
erlang看不懂，python那段如果碰上复杂规则恐怕描述都会出问题，整个就是个枚举规则。 举个例子：4项（a1,a2,a3,a4）满足两项=50就加10 discount_rules=[(lambda member:member.a1==50 and member.a2==50,discount_add10), (lambda member:member.a1==50 and member.a3==50,discount_add10), (lambda member:member.a1==50 and member.a4==50,discount_add10), (lambda member:member.a2==50 and member.a3==50,discount_add10), ... ] 只要出现交叉条件，枚举性描述必然会混乱不堪。 你这个例子,属于是数据结构设计的问题而不是表驱动的问题. member.alist=[member.a1,member.a2,member.a3,member.a4........], discount_rules=[(lambda member:length([for T in [(X,Y )for X in member.alist for Y in member.alist if id(X)!=id(Y)] if (T[1]==50 and T[2]==50)])!=0 ,discount_add10), ... ] 另外关于表驱动的问题回到文章头上看第一段.在那里都说了.二维表驱动要保持范式必须进行分解.但是消息分派不仅仅是表驱动.你可以像Prolog那样组织表中表或者说分派树进行递归回溯. |
| 返回顶楼 | |
