一、术语辨析
相信所有人都知道文档的重要性，尤其是对于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系统似乎并未解决这一问题。
