ASP.NET Atlas对JavaScript的扩展

Atlas对Function,Array,String的扩展是通过prototype来扩展的,这也是javascript中的唯一的选择,也是Atlas的基础性的建设。我说的Atlas内部函数的倾向是指架构中类(class)以及继承等的实现。可以看出,在Atlas中除了对Function,Array,String,Date的扩展和对Event的实现外,其他类的实现均是通过内部函数的方式,而不是prototype的方式,前面我说过,内部函数的方式有存在的必要性,但除非必要(比如你要实现一个供setTimeout使用的回调函数等),在javascript中对类实例的方法的标准实现是通过prototype的,这是ECMAScript的规范。当然不是说通过内部函数的方式实现不可以,就是存在内存和效率问题,如果一个类的实例可以预见到不是很多,则无所谓了。如果比较多的话,问题就来了。

我认为,在Atlas的客户端脚本中存在的某些倾向有一定的问题:

1. 为了语法的完整大量采用内部函数来实现类方法,前面已经说的够多的了。

2. 过份强调了严密性而放弃了灵活性和效率。典型的就是对对象属性的实现方式。大量采用了get_ set_ 这样的内部函数。就其好处,当然首先保证了私有变量安全,另外可以对属性的值进行校验,便于扩展,还有就是可以触发事件或者其他的联动计算来保证数据的完整性。另外在解析xml脚本时保证来对属性访问的合法性。PME的概念在.net中可以说时很普遍,也是C#,VB.net等语言固有的特性,但这些并不是javascript固有的特性,可以说javascript语言从设计到发展到标准化(ECMAScript)都不是这个方向,从将来的趋势来看也没有这种趋势。因为客户端脚本的目标和一个编译性语言时不同的,他的特点时简洁、灵活、强大,他存在于宿主环境中,他最主要的目标是操作宿主对象,所以对自身的面向对象的特性方面要弱一些,而且并不严密,存在很多不足。若非要那他来建立一个“坚固”的客户端脚本环境,我不会看好这个方向,或许微软把Jscript.net强制放在IE环境下会比在jscript中磕磕绊绊地模拟好一些,但这是不可能的。要我来说的话,那些大量的set_get_还是扔了吧,尽管他有不少好处,但和付出的代价来说,太不划算了。

Atlas的抱负可能太大了一些,依我看,照此路发展下去(不仅仅是客户端脚本),很难成功。当然对于微软来说,没有什么是不可能的,我们还是拭目以待吧。

回复 引用 查看