扩展JavaScript的时候，千万要保留其原来的所有功能，因为不知道别人的代码是否会用到这些。而且一般来说，为了写出兼容更多JS框架的代码，最保险的方法就是用JS的原生功能。然而……
在这个问题上，这次ASP.NET AJAX RC栽跟头了。
不知道大家有没有看过ASP.NET AJAX Library RC对于JavaScript的扩展？在RC的扩展中增加了这么一些代码：
Date._jsParse = Date.parse;
...
Date.parse = function Date$parse(value, formats) {
...
}
上面的代码将Date.parse的原生实 现改成了Date._jsParse函数，而自己重新定义了一个Date.parse方法。这样做的话，把Number、Date、Boolean对象都 提供了比较统一的parse功能，并且能够支持各种Format并具有本地化功能，着实是不错的扩展。可惜就是因为改了JavaScript的原生功能， 让Google Ads这个被广泛运用的……玩意儿，就这么Break了。
这个问题可是直接涉及到广大人民群众的切身利益，严重影响了人民群众的感情。比如在ASP.NET AJAX论坛，就在抱怨这件事情（
[url]http://forums.asp.net/thread/1499508.aspx[/url]），不过有问题自然就有人会解决，例如Cyril（一看到这张脸就觉得眼熟，原来我当时的《
另一种Atlas Scripts Intellisense的方法以及对比与分析》就是引用了他Blog上的方法）提出了一种解决方案：
Date.__cyril_parse = Date.parse;
Date.parse = function(s){
try {
return Date.__cyril_parse(s);
} catch (e){
var d = Date._jsParse(s);
if (d) {
return d;
} else {
throw e;
}
}
}
只要引入上面这段代码即可。这是很容易想到 的做法，不过还真的没有比这更简单或更有效的解决方案了：把ASP.NET AJAX的Date.parse扩展再另存起来，再重新写一个Date.parse方法，首先尝试ASP.NET AJAX的扩展，如果失败（幸好如果用户按照原来的使用方式会造成失败），则调用JavaScript的原有功能。问题就这么被解决了，不是吗？
这次ASP.NET AJAX RC的错误很低级，还好只是RC，有问题还不怕。不过，这也不就是RC Release的目的吗？至少现在基本上可以肯定，ASP.NET AJAX正式版里的扩展不会再有这个错误了。
本文转自 jeffz 51CTO博客，原文链接：http://blog.51cto.com/jeffz/60374，如需转载请自行联系原作者
