![](https://csdnimg.cn/release/download_crawler_static/10854020/bg3.jpg)
Tcl Style Guide August 22, 1997 3
3. Packages and namespaces
Tcl applications consist of collections of packages. Each package provides code to implement
a related set of features. For example, Tcl itself is a package, as is Tk; these packages happen
to be implemented in both C and Tcl. Other packages are implemented completely in Tcl such
as the http package included in the Tcl distribution. Packages are the units in which code is
developed and distributed: a single package is typically developed by a single person or group
and distributed as a unit. It is possible to combine many independently-developed packages
into a single application; packages should be designed with this in mind. The notion of
namespaces were created to help make this easier. Namespaces help to hide private aspects of
packages and avoid name collisions. A package will generally export one public namespace
which will include all state and routines that are associated with the package. A package
should not contain any global variables or global procedures. Side effects when loading a pack-
age should be avoided. This document will focus on packages written entirely in Tcl. For a dis-
cussion of packages built in C or C and Tcl see the Tcl/Tk Engineering Manual.
3.1 Package names
Each package should have a unique name. The name of the package is used to identify the
package. It is also used as the name of the namespace that the package exports. It is best to
have a simple one word name in all lower-case like http. Multi-word names are ok as well.
Additional words should just be concatenated with the first word but start with a capital letter
like specMenu.
Coming up with a unique name for your package requires a collaborative component. For
internal projects this is an easy task and can usually be decided among the management or
principal engineers in your organization. For packages you wish to publish, however, you
should make an effort to make sure that an existing package isn’t already using the same name
you are. This can often be done by checking the comp.lang.tcl newsgroup or the standard Tcl
ftp sites. It is also suggested (but not required) that you register your name on the NIST Identi-
fier Collaboration Service (NICS). It is located at: http://pitch.nist.gov/nics
3.2 Version numbers
Each package has a two-part version number such as 7.4. The first number (7) is called the
major version number and the second (4) is called the minor version number. The version num-
ber changes with each public release of the package. If a new release contains only bug fixes,
new features, and other upwardly compatible changes, so that code and scripts that worked
with the old version will also work with the new version, then the minor version number incre-
ments and the major version number stays the same (e.g., from 7.4 to 7.5). If the new release
contains substantial incompatibilities, so that existing code and scripts will have to be modified
to run with the new version, then the major version number increments and the minor version
number resets to zero (e.g., from 7.4 to 8.0).
3.3 Package Namespaces
As of version 8.0, Tcl supports namespaces to hide the internal structure of a package. This
helps avoid name collisions and provides a simpler way to manage packages. All packages
written for Tcl 8.0 or newer should use namespaces. The name of the name space should be the
same as the package name.
3.4 Structure
There are a couple of ways to deploy a package of Tcl commands.
• A pkgIndex.tcl file is used to create packages that can be loaded on demand by any Tcl
script. Like a tclIndex file, a package specifies a set of Tcl and/or shared libraries that