敲响OO时代的丧钟！——DJ对于数据持久化的支持(3)

为什么DJ要将Event提出作为语法概念

http://spaces.msn.com/members/zbw25/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!358.entry

不好意思。其实我对DJ中Channel并不是很了解。只是因为channel这个名字,hehe.
PI演算中的channel的类似的地方是都作为数据传输通道，并且Channel本身(或者是用于唯一指代或寻址channel的名字/地址)还可以作为被传输的数据，接收者相当于握有通过这个chennel与属主(某进程，或许不应该叫进程，叫对象？Agent? 但是英文是process)进行交互的能力，即channel是可传播的((这一点是PI演算区别于前任CCS的本质之一)。如果把channel和OO语言中的某些东西(函数？方法？closure?)作一个映射，会得到一些很有意思的东西。
不过，我对DJ中的channel确实不是很了解。

提供一点建议和线索，不知道老庄看过Agent OP没有？
我有一点感觉，你的DJ似乎能跟Agent OP结合起来。

没看过呀，能不能先简单介绍一下。

我主要是因为DJ会引入语言级的event支持才有这种想法的，不知道DJ对异步或者并发的支持会是怎样？
简单地说，AgentOP的模型比OOP的模型更动态一点，对世界的描述更加贴近人类的概念。Object是被动的，只能接受外界的调用，而Agent是主动的对象，不但对外界的刺激有反应，自己也可能主动刺激其他的Agent。通常来说基于AgentOP的系统是天然并行的。先不谈主动性的问题，并发的情况日常还是常见的。
事件系统肯定遇到并发的问题，B对A发送一个事件的时候，A可能正忙（比如进入关键区锁定了），从AgentOP的观点来看，应该由A来决定如何对待这个事件。
举个例子，比如A放好了锅B煮鸭子，然后A去听新闻，等鸭子熟了，锅B就会放出一个事件E通知A。
现在的主流的语言中，锅B会强行抓A去把火熄掉（参考Observer）。
但是如果A正在处理一个严重的事件C，比如听说海啸了（也就是进入关键区之类的，锁定了资源），那么这时候应该怎么处理后来的事件E？
目前的来说，一般后来的事件E（以及事件发出者B的行为）会被阻塞。
然而从AgentOP的观点来看，是阻塞事件E还是放弃之前的事件C优先处理事件E，应该由A来决定（因为只有A才知道事件C跟事件E，哪个对A更重要）。
如果A决定稍后处理事件E（Observer返回），那么锅B应该继续运行下去。
如果语言没有辅助设施的话，可能要采用类似下面结构的代码

    void duckCooked(CookEvent cookEvent);{
         eventQueue.push(cookEvent);;
         // process it later
    }

可是这样就存在什么时候去处理eventQueue中的对象以及如何处理的问题。
如果由A自己负责，A就要自己根据事件的类型向自己的事件处理方法分发事件。
总之，费力且混乱。
如果语言层面提供了event以及动态将一个事件转化成异步事件的辅助设施的话，AgentOP的实施就更加方便可行了。

haha
兄弟我很多年前就是搞Agent的。Agent的概念比起OO来在抽象层次上又进了一步，直观上也更加自然。
不过，当时除了某几个小流派以外，个体研究的主流还是搞那种慎思型(Deliberative)Agent，基本用那些BDI和Goal等概念，要有一些逻辑基础(主要是模态逻辑和可能世界语义学)才能闹明白，不过现在没多少人搞个体了，基本上都在搞群体和交互，所谓的社会Agent。而且，正儿八经把玩起来，缺乏一个和逻辑相结合的适合于并发系统的操作语义(前面说的那个PI演算也可以用作一个，但它针对的是交叠式并发，而不是真并发，Perti网是真并发，但太琐碎)。我估计在一个强大快速并且有适当语义支撑的推理引擎出现之前，进入实用还不太容易。
现在的Object，可以归类到其中的刺激反应型agent. 不过，即便是这类Agent，也应当是自治的，或者说是自身利益导向的。这可能和Ｏｂｊｅｃｔ的概念有本质上的区别。当然，这种利益导向怎么表现出来，则需要一套很复杂的机制。

to:厌倦发呆
:D
太巧合了，我打算引入的event，的确包含两种event，只是用什么关键字，我还没有想好，所以也没有写出来。

也许叫asyn  event作为异步事件，sync event作为同步事件，其中sync可以省略。

对于一个希望接收与处理事件的channel来说，他在声明event的时候，就可以决定这个事件他是否需要同步的处理。

也就是说：当一个事件A发生，需要触发ChannelB中的处理函数，之后当处理函数完成，A事件才可以继续，或者才算完成，这算是同步事件。

当一个事件A发生，无论ChannelB中的处理函数什么时候处理，A事件都可以继续的，就算是异步事件。

你看是不是和你说的AgentOP非常类似？

庄子的思路逐渐浮现了出来。果然很大气，考虑的很深入，指出的很多开发中的问题，也是非常精辟。比如，关于“CGLib走入了邪路”，完全赞同。
但是，对于DJ，我目前的理解能力似乎还不够，无法把握DJ是如何解决那些问题的。目前只是感到一些Tips。等待更完整的、大规模的例子。
另外，期待其他的熟悉 函数式编程、动态语言编程、LOP，AOP 的高手，经常跳出来挑战，进行比较和选择。

有一次有幸和raimundo聊天。
raimundo 谈到建议庄在DJ 语言中引入 Ontology, 谓词。类似于对Class, method 的规则定义。后来终于理解了一点，管中窥豹，尽管不能完全理解清楚。

CGLIB 完全走入了邪路。 这句话我不赞同！

对于框架性的代码，bytecode 级别的修改还是很有必要的。 CGLIB提供了一个修改Bytecode的对象性框架，它的出现是出于performance 和 易用的考虑，提供这种级别的封装对很多人还是很有帮助的。

:D
其实“邪路”是一个赞叹的词。
修改bytecode，这和那些走上邪路的 病毒/破解 黑客干的事情，差不多。需要比较深的基本指令的功底。
而一般的程序员，不具备这种能力，不具备走上邪路的资格。正所谓“邪”亦有道。
好处就是，为有黑客梦想的程序员提供了一个施展的空间。
动态语言就不行了。根本用不着bytecode修改，语言级别就支持。普通程序员都能做到动态增强，这也太没劲了。一点找不到底层黑客的感觉。

从我的感觉上，具有源代码的Open Source Project都具有很多bug，谁知道bytecode 修改会不会引入更多的bug，会不会安放一些后门？毕竟，那些指令操作，不如java source容易看懂。

由于连生成的源代码都没有，普通程序员只好信任某些框架进行“暗箱操作”，假设它修改的bytecode是正确的，没有引入任何隐患。