關於qomo中namespace系統的初步探索

一、術語辨析

相信所有人都知道文檔的重要性，尤其是對於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系統似乎並未解決這一問題。