关于qomo中namespace系统的初步探索

原创 2006年02月23日 15:30:00

一、术语辨析

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

 

使用系统命名空间using namespace System的方法

在我们使用VS2008编程时,可能会用到系统的命名空间,但是在直接使用时经常出现问题,比如:   using namespace System; VS2008会报错,说找不到system等名,这是因为...
  • Gushleo
  • Gushleo
  • 2013年07月07日 15:58
  • 2451

Linux内核源码分析-安装实际根文件系统- prepare_namespace

Linux内核源码分析-安装实际根文件系统- prepare_namespace 内容说明: 1、不描述内核同步、错误处理、参数合法性验证相关的内容 2、源码摘自Linux内核2.6.11.1版 3、...

Android N加载系统私有库时出现is not accessible for the namespace错误和针对该错误的解决方法

谷歌从Android N开始,除了那些在Android NDK提供的库之外,限制了应用对系统私有库的加载。本文介绍了如何应对这种情况。...

Qomo V2.1beta.2008.10.14

  • 2008年10月15日 10:46
  • 937KB
  • 下载

Windows系统安全初步探索

  • 2014年01月07日 20:45
  • 374KB
  • 下载

Android 系统的java世界是怎么诞生的?孵化器zygote的初步探索

1---->app_main.cpp   (zygote进程)的入口,这个肯定是init进程来调用的)   int main(int argc, const char* const argv[]) ...
  • liuxiIT
  • liuxiIT
  • 2014年07月29日 23:36
  • 1886

周爱民Qomo框架源码

  • 2009年12月10日 18:33
  • 1.04MB
  • 下载

autoload与namespace实例

  • 2016年03月25日 15:15
  • 2KB
  • 下载

Kafka-分布式系统初步

首先我们要明白什么是消息系统,在kafka官网上对kafka的定义叫:A distributed publish-subscribe messaging system。publish-subscrib...

struts2_namespace代码

  • 2016年01月23日 00:20
  • 4.6MB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:关于qomo中namespace系统的初步探索
举报原因:
原因补充:

(最多只允许输入30个字)