|
锁定老帖子 主题：失踪的链环
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-10-08
Trustno1 写道 charon 写道 不是因为具有行为，而是因为具有名字为xxx/yyy的行为，所以显现zzzzzzz 所以这里和是不是具有某种性质的行为是无关的，只是说具有某种名字的行为。 而静态语言的接口，通常会对其方法的语义加以约束(虽然不能从语法上表示出来，但会通过文档等等) 那来的那么罗嗦的事情,duck typing就是一个request/response的过程.走在大街上我见到一个人很像你 于是我叫了一声charon,于是你抛给我一个媚眼.问题是我叫一声猪,你肯定头也不回的往前走.这就是所谓的 "我本将心向明月奈何明月照沟渠" 如果仅仅是这样，事情会简单很多。 问题是为什么只向人问候, 因为你首先判断对方是一个人(类型)，然后在从外形(而不是动作)判断是不是一个特定的人(人的实例charon). 这个并不是无类型声明语言的工作方式. 无类型声明语言的工作方式，大致是过来一个东西，就问候它一声，比如猪/狗/狼/人,显然这帮家伙都能对问候产生一定的反应，但是,但是如果你向一只猪问候"charon"，它最多吭哧吭哧,而如果问候一头狼,则很可能产生严重反弹. |
| 返回顶楼 | |
|
发表时间：2006-10-08
charon 写道 Trustno1 写道 charon 写道 不是因为具有行为，而是因为具有名字为xxx/yyy的行为，所以显现zzzzzzz 所以这里和是不是具有某种性质的行为是无关的，只是说具有某种名字的行为。 而静态语言的接口，通常会对其方法的语义加以约束(虽然不能从语法上表示出来，但会通过文档等等) 那来的那么罗嗦的事情,duck typing就是一个request/response的过程.走在大街上我见到一个人很像你 于是我叫了一声charon,于是你抛给我一个媚眼.问题是我叫一声猪,你肯定头也不回的往前走.这就是所谓的 "我本将心向明月奈何明月照沟渠" 如果仅仅是这样，事情会简单很多。 问题是为什么只向人问候, 因为你首先判断对方是一个人(类型)，然后在从外形(而不是动作)判断是不是一个特定的人(人的实例charon). 这个并不是无类型声明语言的工作方式. 无类型声明语言的工作方式，大致是过来一个东西，就问候它一声，比如猪/狗/狼/人,显然这帮家伙都能对问候产生一定的反应，但是,但是如果你向一只猪问候"charon"，它最多吭哧吭哧,而如果问候一头狼,则很可能产生严重反弹. 要这样讲,就有有趣的问题了.你是怎么判断那是个人呢?肯定是对方身上的光线反射到你眼睛里，你才能知道他是个人.不要以为我是在抬杠.现实生活中光当然是一个重要的消息传递机制,具体的可以参看SICP第三章关于并发那章最后一节的注释.这的确最后归于一个哲学问题.是必须有操作有观测才能确定对象的存在呢?还是不作观测对象也存在?说远了在具体的可以去翻以前robbin贴得量子力学史话,这个问题就此打住.我不想再过多的扯上哲学话题. |
| 返回顶楼 | |
|
发表时间：2006-10-08
raimundox 写道 charon 写道 不是因为具有行为，而是因为具有名字为xxx/yyy的行为，所以显现zzzzzzz 所以这里和是不是具有某种性质的行为是无关的，只是说具有某种名字的行为。 你这个从理论上讲是不错的，但是从实际上讲毫无意义。比如我们我有一个方法叫getName(),但是我偏偏要返回年龄，这里无论那种语言都无法解决。 这个可以用停机定理来说明，停机是某种特定性质的行为，但是这个是不可用程序判定的。因此，也就是说，无论哪种语言，编译器都无法判定某个方法是否具有特定性质的行为。无论smalltalk,ruby,java或是c＋＋，我们所能依赖的只有名字。 不懂,编译器也无法判断注释是不是具有某种特定的性质,但是我们仍然在写注释.如果getName是某个接口中的一个方法,并且已经在注释中约定只能返回名字. 任何一个开发者都不会刻意去期待接口的实现者会去违反这个显式的约定. 当然,对于简单的能够形成共识的名字,隐式的约定不会产生问题.但是对于复杂一些的构词法,如果不是足够复杂到能够搞定歧义性,不同的人对同一名字的认识的不一致性必然会出现.名字空间能够解决一部分问题,但只是一部分而已. 接口是有类型声明语言的解决办法之一,每一个这个接口的使用者,如果发现疑义,在现代IDE中很简单就能察看这个接口的约定,这个注释是写在被调用方,或者消息的接收方. 而无类型声明语言,如果要把一个对象传入某个方法,必须事先了解这个方法会对传入的对象干点什么,并需要这个对象提供点什么功能,此时,约定是写在(如果需要明确的话)这个方法的内部,即对象的调用方(或消息的发送方)的. 这两种注释的出现位置各有利弊,而且是两种截然不同的思考方式,但是多数人还是习惯前者. |
| 返回顶楼 | |
|
发表时间：2006-10-08
Trustno1 写道 要这样讲,就有有趣的问题了.你是怎么判断那是个人呢?肯定是对方身上的光线反射到你眼睛里，你才能知道他是个人.不要以为我是在抬杠.现实生活中光当然是一个重要的消息传递机制,具体的可以参看SICP第三章关于并发那章最后一节的注释.这的确最后归于一个哲学问题.是必须有操作有观测才能确定对象的存在呢?还是不作观测对象也存在?说远了在具体的可以去翻以前robbin贴得量子力学史话,这个问题就此打住.我不想再过多的扯上哲学话题. 是啊.本来我也想从物理的方向更加深入一点,都是发现这样就会没完没了. 如果要继续讨论这个方向,有一个抽象的粒度问题,还有行为的主动性和被动性问题.实际上,用自然界来类比,仔细推敲之下都会有问题. 就比如这里一般物体都能反射光,显然光反射这个极细粒度方法不能成为判断的依据. 相比于粒度,主动性和被动性其实是一个更好玩的话题. 不过这个都是哲学问题,哲学问题.... 至于并发,既哲学又实际,很难讨论,SICP的那些文字也只是浅掠而已.我记得一般玩并发,开篇都是先明确自己讲的是真并发还是交叠式并发的....... |
| 返回顶楼 | |
|
发表时间：2006-10-09
后面的越扯越远了...
|
| 返回顶楼 | |
|
发表时间：2006-10-09
看了半天（太长）才知道说的是什么事情。
这个东西在非oo思维中根本不是问题。 oo思维的强项之一就是把某些本来很简单直接的思维弄复杂。 重用的思想更加加深了这种趋势。 对于信仰oo思维的人（不是使用oo的人）来说，这倒是无所谓的代价。 |
| 返回顶楼 | |
|
发表时间：2006-10-10
这个python程序只解决了叠加式规则，也就是说，一组规则，大家挨个匹配，遇到哪个合适的，就用。
那么怎么对付互斥式的呢？一组规则，顺序走下去，遇到一个匹配的就停止。 更一般的，怎么对付规则组合？规则可不可以是first class的？有没有higher-order rule？比如参数是一个规则，返回值是一个规则之类？ 这些又怎么用消息分派诠释？ |
| 返回顶楼 | |
|
发表时间：2006-10-10
ajoo 写道 这个python程序只解决了叠加式规则，也就是说，一组规则，大家挨个匹配，遇到哪个合适的，就用。
那么怎么对付互斥式的呢？一组规则，顺序走下去，遇到一个匹配的就停止。 更一般的，怎么对付规则组合？规则可不可以是first class的？有没有higher-order rule？比如参数是一个规则，返回值是一个规则之类？ 这些又怎么用消息分派诠释？ 遇到匹配的就停止,higher order rule,并不是一个消息分派上的问题,是一个如何计算上的问题.消息分派只是让你取到规则,至于规则之间怎么计算是另外一回事情.像前面Python那个例子,for 循环里面对 所有的rule进行累加是如何计算的例子.你同样可以把如何计算的算法抽取出来,比如说后面用模式匹配的例子就是把 sum和max 抽取出来只负责计算,而每条rukle只负责把自己的计算规则简单的累加到一个列表里面,等所有的消息匹配完了,在外面对规则列表里面所有的数据进行计算. 引用 sum(Discounts)->lists:foldl(fun(X,ACC)->X+ACC end,0,Discounts).
max(Discounts)->lists:foldl(fun(X,ACC)when X>ACC->X; (_,ACC)->ACC end,lists:map(sum,Discounts)). discount(_,[done|Discounts])-> sum(lists:map(fun max/1,Discounts)). 这是最简单的high order 计算的例子. 至于 比如参数是一个规则，返回值是一个规则之类,这到是一个消息分派上的问题.类似于网上流行的真心话达冒险,我回答了一个问题，把问题传给下一个人，下一个人回答问题然后再添加一个问题变成两个问题传给下一个人.消息体会随着消息的传播而改变。 |
| 返回顶楼 | |
|
发表时间：2006-10-10
higher-order rule。 把一个 DSL 字符串传来传去就行了吧。 说到 message dispatch. 我倒是觉得，我做的fastm template的基于hash key的分支处理方式可以说是简洁有效的经典模式。:D key1 -> branch 1 key2 -> branch 2 |
| 返回顶楼 | |
|
发表时间：2006-10-10
actionA: condtion1->action1
actionB: condtion2->action2 执行方式为 exclusive(actionA,actionB) 或者 list(actionA,actionB) 等等其他 消息分派并没有解决执行方式的问题，也就是执行规则list exclusive并不属于消息分派解决的问题域？ 执行规则不会超出逻辑运算的闭包， 跟解释逻辑表达式树执行方式一致，应该可以统一出搞一个东西 另外Trustno1能不能讲讲FP的错误处理都是怎么做的？ 尤其是错误处理非常复杂的地方 |
| 返回顶楼 | |
