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上可能存在问题。这部分晚点在作讨论。