讨论：Qomolangma实现篇(四)：基本特性增强与多投事件系统
讨论：Qomolangma实现篇(四)：基本特性增强与多投事件系统 http://blog.csdn.net/aimingoo/archive/2006/03/07/617363.aspx
“不修改Object()对象原型”，我还是比较赞同这个的，因为这样可以避免影响到 for in 的惯用法。假如框架的一个目标是尽量能兼容已有的代码，则这个规定是必要的。不过这样也限制了一些能力。有一种折中的方案，是我从Dean的ICommon认识到的，即可定义一个新的类作为基类。反正要改变用户习惯，则连基类都一并修改也无妨。
关于format，个人不喜欢%n或者$n的format方案，而更喜欢${xxx}或者{$xxx}的动态字符串方案。这个基本上属于编程背景和个人喜好问题，除了后者可以使用名字而不受顺序的影响（单纯数字容易造成bug）这个小优点。
此外，我觉得最好不要增加format为全局函数，因为format这个词太常用，容易造成冲突。我认为可以仿效js 1.6（moz所实现的）中Array和String的generics，增加String.format()静态方法。
关于addMethod，我建议是不是可以把add方法修改为add(handler, thisObj)，即addMethod的两个参数顺序颠倒一下，并且将后者作为可选参数。moz下js1.6的新增的一些方法就是如此。若是嫌addMethod方法多余，去掉也可，或者也可提供多一种选择，保留该方法。
reset(x)方法我觉得是多余的。仅仅提供一个clear(); add(x)的缩写似乎不太经济。
close()的设计目的我理解是类似于java中的final，禁止override。个人认为，假如要提供这样的功能，应该在体系中以更加一般化的形式体现，即不仅对于事件（禁止增加句柄），而且对于方法（禁止override），甚至对于类（禁止继承）。另外，建议把方法改名为seal()。
关于del，首先俺更prefer的方法名字是remove而不是del。其次，“能导致事件的激活顺序被破坏”不知道是什么意思。如果是指多个事件句柄的执行顺序，我认为不应考虑。我看到的多数事件体系都不保证多个句柄的先后顺序。“del()需要执有内部“事件句柄列表”中的事件方法的引用，这破坏了封装性”，这一句不明白。
关于强壮的MuEvent。。。我觉得这部分考虑的太多了，从而造成引入了一些额外的复杂性。使用valueOf的想法是好的，但是在moz上可能存在问题。这部分晚点在作讨论。
