关于qomo中namespace系统的初步探索
一、术语辨析相信所有人都知道文档的重要性,尤其是对于open source的项目来说,完善的文档是成功必不可少的。因此,在文档中使用统一的、尽量准确无歧义的术语是非常重要的。在这方面,中文有着先天劣势,因为绝大多数技术用语都是英文确定的,而这数年来,术语翻译的混乱程度有增无减,相同的词有不同译名,不同的词翻出来却一样,这给阅读中文文档造成极大的困难。所以,即使不考虑到项目的国际化,我也强烈建议
一、术语辨析
相信所有人都知道文档的重要性,尤其是对于open source的项目来说,完善的文档是成功必不可少的。因此,在文档中使用统一的、尽量准确无歧义的术语是非常重要的。在这方面,中文有着先天劣势,因为绝大多数技术用语都是英文确定的,而这数年来,术语翻译的混乱程度有增无减,相同的词有不同译名,不同的词翻出来却一样,这给阅读中文文档造成极大的困难。所以,即使不考虑到项目的国际化,我也强烈建议,对于文档中的核心术语和概念,不仅要有中文,也要附上准确的英文。因为,对于使用者来说,他多少总是首先接触到其他语言的概念和用语,总是自觉不自觉地以既有经验来理解新事物。许多人在看到中文术语时候,首先会把它翻译成一个对应的英文术语,这样极有可能的造成错误的概念映射。
在这方面,qomo有很大的不足。特别是,我觉得,qomo既然是一个js框架,就应该最大限度的遵守js长期以来形成的术语使用规范和惯例。例如我在前面的讨论中所指出的Scope、Context的情况。js本身就是一个最受误解的语言之一,因此在js术语方面有水土不服的现象也十分正常。我自己也常常会乱用。不过在正式文档中,我们应该尽量避免误用或歧义。
二、术语“命名空间”和“包”
qomo所带的文档“命名空间的支持”中,首先做了概念约定。由于qomo并没有给这些术语附加英文,或者以其他语言如java或c#作出类比,则我仅是根据我看文档和代码的理解作一讨论,与作者原意也许会如有出入。
命名空间:从与aimingoo的交流确定,命名空间大体是指形如com.example.abc这样的,即类同于c#的namespace或java的package。
包:从文档和我的理解看来,qomo的包是指一组程序集,也许可类比c#的assembly或java的jar。
这里有两个问题,第一,qomo虽然定义了命名空间和包,但是却没有指出这两者是什么关系,由于译名问题,这造成困惑。第二,在对包进行解释的时候,又使用了“单元”这个未定义的术语,在“文件和包的导入”一文(内部标题为“$import函数的使用”)中,也使用了“js单元”的说法。
关于namespace/package与assembly/jar的关系,我会另文阐述我的看法。这里仅仅提出几点:
1. 我们惯常把java的package翻译成“包”,而实际上java的package与c#的namespace是等价的,对于多数跨java/c#的程序员来说,头脑中的映射多数是命名空间=namespace=package=包。所以,qomo这里的定义造成了理解上的困难。尽管,可以通过更详细的文档来指明,但是更好的做法是给“包”、“命名空间”改个称谓,例如可以把“包”改为“程序集”。(但其实我觉得,出于js的特性,这个“包”其实并非必不可少,也较少实用性,目前qomo的实现也仅是通过一个中间的js来导入所有“包”中的文件,出于简明的考虑,可以删去。详细见后。)
2. 如我前面所说的,qomo作为js框架应尽量采用js规范和社区的术语惯例。而ECMAScript的下一个版本edition 4(即JavaScript 2.0),增加了package和namespace机制。注意,js2的package是类似c#的namespace和java的package的,而js2的namespace机制则完全是另一个东西,可用来实现访问控制(private、public、internal等)和版本(version)。js2规范草案中写道:Unlike in C++, a namespace is not a scope and does not contain any names or properties itself; a namespace only modifies the accessibility and visibility of names or properties attached to activation frames, classes, or objects.
也就是,js2的namespace可能有点像某一种用于编译器的attribute(c#)或annotation(java)。
尽管js2规范可能从草案开始发生剧烈的变化(关于其namespace机制是否会发生重大变化,我不太清楚),但使用package作为关键字估计是不会变的。有两个主要原因,第一,package是以前所保留的关键字,第二,JScript.NET和ActionScript 3作为目前js2规范草案的部分实现,都部分实现了草案的package机制。
由于上述两点,我建议qomo考虑换用package这一在js领域广泛接受的术语,而不是“命名空间(namespace)”。当然在文档中可以指明其与c#的namespace的类同性,正如JScript.NET所作的那样。
三、是否需要“包”
我猜测,qomo对“命名空间”和“包”的划分,以及坚持使用“命名空间”作为术语,可能是受到c#对namespace和assembly划分的影响。传统上,java虽然也有jar,但仅仅作为一种方便的部署方式,package的层级命名强制要求物理上的层级组织(这种严格规范是java的设计哲学之一,并非其考虑不周)。c#则把namespace仅仅作为命名,而与代码的物理组织方式剥离,特别是,规定internal不是对于namespace而是对于assembly(所以internal不等于java的默认包级访问权限),从而使得assembly有了语义上的涵义。在这里我无意讨论java和c#的设计孰优孰劣,但必须认识到,命名空间和物理路径的分离并不意味着必须要有assembly,特别是qomo没有internal这样的访问权限控制,故即使有“包”也没有语义上的作用。assembly和jar如果仅仅作为部署的单位,则没有必要在qomo的核心部分引入这样的定义和功能。实际上,js长期以来的实践是,使用单个文件作为复用单位(js不太讲部署这样重型的词)。如果文件太大,可以拆分成几部分,然后主文件进行include。在一个复用单位的内部,使用这样的技巧似乎已经足够了。当然我也并不排斥在qomo的核心部分之外,再加上一些部署机制,甚至如压缩包、数字签名包这样的。
下一次,我将会讨论js的全局命名空间污染问题。qomo的namespace系统似乎并未解决这一问题。
![Logo](https://devpress.csdnimg.cn/79de2bf0b7994defa4242ef90d5513fa.jpg)
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)