Addition of a global namespace function?

Mark A. Ziesemer online at
Wed Dec 2 21:11:06 PST 2009

On Wed, Dec 2, 2009 at 5:26 PM, Mike Samuel <mikesamuel at> wrote:

> What is the goal of namespaces?
> To prevent one module from (unintentionally|intentionally|both)
> clobbering an API exported by another module?

I'm not sure using "modules" is the correct term in this context.
However, the goal of JavaScript "namespacing" as I see it is to
prevent one section of code from unintentionally clobbering another
section of code, due to naming collisions.  This could be combinations
of code from one or more developers, organizations, or products.

Imagine a typical, modern web page.  Consider
It appears quite clean with only 4 *.js files loaded:,
jquery-1.3.2.min.js, jquery-ui-1.7.2.custom.min.js, and urchin.js
(older version of Google analytics).  The first 3 are already very
well behaved, actually following the exact standard I'm proposing with
nested namespaces, including:

(many other jQuery objects)
(other org.mozilla.*)

I'd actually prefer that "jQuery" was "com.jquery", but it is
certainly an effort towards namespacing.  For both jQuery.* and
org.mozilla.*, my proposed namespace function could be used to help
create these nested objects.  Currently, each script needs to find a
way to do this itself, or depend upon another library that provides an
appropriate namespacing function.  Mozilla's is:

 * Namespace
if (typeof org == 'undefined') {
    var org = {};

org.mozilla = function() { /* ... */ }

With my proposed addition, this would simply be:

namespace("org").mozilla = function() { /* ... */ }

or even shorter:

namespace("org.mozilla").init = function() { /* ... */ }

urchin.js, on the other hand, could certainly use some better
namespacing.  The only convention used is that everything begins with
"_u".  There's no standard or anything else to discourage any other of
many, many other JavaScript developers to also develop a common
library that is prefixed with "_u".  Furthermore, as this method of
"namespacing" is not using nested objects, it is contributing towards
global namespace pollution
( ,
). shows Google Urchin as having 76
global variables, with 73 in the current version hosted at  Fortunately, Google seems to have paid attention to
this, as their newer version (ga.js) places everything as a child of
"_gat" (Google AnalyTics?).  Again, I would have preferred something
like "", but this is definitely a significant
improvement from before.  ga.js is quite obfuscated, but it is clear
that they are also using nested objects to achieve proper namespacing.
 As part of this, they are surely having to create these nestings
someplace themselves, and could also benefit from the global namespace
function that I am proposing.

This is not only an issue with web pages, but other products where
JavaScript may be mashed together.  This includes - but is not limited
to - Mozilla Firefox and its extensions, as mentioned in the
previously linked .

> What is a namespace?
> An object that can be consistently addressed by a dotted path after first read?
> A chain of property names starting from a container that should always
> return the same result after first read?

For a general definition of a namespace, I'll defer to Wikipedia: .  (This
also happens to list a number of drawbacks against using the "prefix
namespacing" approach as a work-around, mentioned at .)

In JavaScript, it seems that I and many others (including the above
examples of, jQuery, and Google Analytics) agree that
namespacing is best accomplished using nested objects, or a "dotted
path" as you mentioned.  There just isn't anything (yet) built-in to
the language to support this beneficial practice.

I would contend that namespaces are, and should be dynamic - so that
they do not always have to return the same result after the first
read.  I'm not saying that doing so is a bad practice, but I don't see
any reason to introduce artificial limitations to prevent doing so.
Also, as being discussed, a namespace in JavaScript really isn't
anything special - it is one or more objects.  "com.example.x.y.z"
could hold a value, as well as acting as a namespace for other child
namespaces or values.  Again, I'm not stating that this is a good
practice, but I don't see a need to prevent it.

> Why is namespace not in a namespace?

Because the namespace function should be one of few that are "truly
global", along with the likes of "eval", and global objects such as
"Array" and "String".  (Other global functions include
(encode/decode)URI(Component), is(Finite/NaN), and parse(Float/Int).
It could be argued that these should belong in a namespace, e.g.
Math.* for the later ones.)

The namespace function should also be used to create the namespace
that the namespace function would reside in - which quickly turns into
a paradox.

> From your blog:
> In what sense are namespaces object-oriented?  As I understand the
> term, object-orientation is a way of organizing a program around
> objects that exchange messages.  There's nothing in this proposal that
> deals with messaging or objects -- it seems to be a hierarchical
> addressing scheme.

Maybe a better way to state this is that the proposed method of
namespacing in JavaScript makes use of its OO support, namely objects
supporting child properties and methods.

> When you talk about namespace aliasing, should namespaces be treated
> as first class?  If namespaces are aliasable, should they be marked
> unconfigurable to prevent property deletion or is that up to the
> namespace user?

Again, namespacing isn't anything "new", and is already being widely
used as shown in examples above.  I'm just proposing the addition of a
global namespace function to make creating new namespaces easier and

The way they are currently being implemented is just through nested
objects.  I'd say that objects already are (or should be) considered
"first class" in JavaScript, so namespaces should be as well.

I would say that namespaces should definitely not be marked
"unconfigurable".  A good JavaScript library, if it has nothing else
to do and no more purpose, should actually remove itself from memory,
and allow itself to be garbage collected.  I don't see any reason to
introduce any barriers to allowing this.

> When you talk about using the "with" statement with namespaces, what
> problem are you trying to solve?  Is this meant to act as a poor-man's
> java import?
> Are you aware of the forward-compatibility problems that "with"
> entails, and the effect it has on tools like YUI compressor, closure
> compiler, etc.?

I wasn't trying to solve any problem.  I only mentioned this as an
alternative, to show the benefits that the nested-object approach has
for namespacing.  I agree, the "with" statement probably causes more
problems than it helps.  (
)  While I didn't show an actual example on my blog post, I did
mention that the previous example would be better done within another

Here is correcting that.  This:

  name = 'Mark';
  location = 'Wausau, WI';

would better be accomplished as something like:

  var czmp = com.ziesemer.myPackage; = 'Mark';
  czmp.location = 'Wausau, WI';

> You mention java packages, which provide namespacing, and information
> hiding.  Is it a goal for this scheme to extend to support information
> hiding as well?  If so, how?

I would not easily agree that Java packages provide information hiding
- though the definition of the term "hiding" is up for dispute.  Java
namespaces allow for organization, and help to prevent naming
collisions.  Java adds some extra features based on these namespaces,
such as package access protection.  There would be nothing to prevent
JavaScript from adding something similar someday.

I guess I would consider the "private" and "protected" keywords more
suited to "hiding" things than packages.  Even then, these keywords
are seldom misunderstood, and should never be used for "security".  A
little reflection can go a long way!

> cheers,
> mike

(I've used the term "JavaScript" throughout this reply.  Really, I
think JavaScript and ECMAScript could have been used interchangeably.)

Mark A. Ziesemer

More information about the es-discuss mailing list