Namespace allocation

+Namespace allocation + +

Similar to Java, the namespace of a extension is hard-coded. One could say that there is no such thing as changing the namespace of an extension; you can stop maintaining the extension in its original namespace and make a clone of it in another namespace, but the users of your extension will need to go through a more or less painful process to migrate from the old extension in the old namespace to the new extension in the new namespace. Using an extension as if it were placed in a different namespace than where it is defined is not possible (since the complexity that such design brings outweighs the benefits).

+ +

For a single user, hard-coded namespaces is probably not a big issue, but the situation gets more complicated when individuals and organizations start sharing code with each other. The risk of conflicting use of namespaces is obvious, and the solution is to define who is in charge of allocating namespaces in various subtrees of the entire namespace tree: +

+
.. is under the control of this very section in the documentation.
+
+
..Shapes is managed by the project and reserved for the core bindings and standard extensions of the language.
+
+
..net is an example of a reverse DNS top level namespace; all lowercase-only top level namespaces are reserved for implicit reverse DNS mapping.
+
For example ..net..sourceforge belongs to SourceForge. This means that SourceForge may decide that each project gets to manage its own namespace, either immediately under ..net..sourceforge, or at some deeper level such as ..net..sourceforge..proj. Note that not all valid domain names have a corresponding namespace, only domain names where each part is a valid have a corresponding namespace.
+
+
..User is reserved for implicit mapping of email addresses to namespaces. Not all valid email addresses have a corresponding namespace, but only those where each part of the host name, and the entire local part is a valid . The mapping is then defined by first doing reverse DNS mapping of the host name, and then append the local part. For example, ..User..net..sourceforge..tiddishsource is managed by the owner of the tiddishsource user account at SourceForce.
+
Normalization of the local part may be applied to yield a valid namespace identifier. For example, a user with email address foo.bar@gmail.com is the manager of ..User..com..gmail..foobar, since gmail.com treats foobar and foo.bar the same. Note that different email hosts may apply different normalizations.
+
+
..Alias is managed by the project and reserved for namespaces explicitly allocated to users of . Each namespace directly under ..Alias is managed by some user, and provide a more compact alternative to the implicitly allocated namespaces under ..User. Each user must provide a valid link for getting in touch, such as an email address, a Facebook account, a SourceForge profile, etc.
+
The following namespaces are currently allocated: + + + Namespace Belongs to + + +
..Alias..tidde

Henrik Tidefelt
+ + +
+
+
..Applications is managed by the project and reserved for generally useful applications that demonstrate the use of the language, and that are distributed together with .
+
+
..Contrib is managed by the project and reserved for user-contributed extensions of general interest that are distributed with . Namespaces allocated directly under ..Contrib shall be listed here, but at the moment there are none.
+

+ +