Namespaces are obsolete

Microsoft.SqlServer.Management.Smo.AgentTo those of us who have been around for a while, namespaces have been part of the landscape. One could even say that they have been defining the large-scale features of the landscape in question.

However, something happened fairly recently that I think makes this venerable structure obsolete. Before I explain this development and why it’s a superior concept to namespaces, let me recapitulate what namespaces are and why they’ve been so good to us over the years…

Namespaces are used for a few different things:

  1. Scope: a namespace delimits the portion of code where a name (for a class, sub-namespace, etc.) has the specified meaning. Namespaces are usually the highest-level scoping structures in a software package.
  2. Collision prevention: name collisions are a universal problem. Some systems, such as jQuery, wave it away, but the problem remains. Namespaces provide a reasonable approach to global uniqueness (and in some implementations such as XML, enforce it). In .NET, there are ways to relocate a namespace to avoid those rare collision cases.
  3. Hierarchy: programmers like neat little boxes, and especially boxes within boxes within boxes. For some reason. Regular human beings on the other hand, tend to think linearly, which is why the Windows explorer for example has tried in a few different ways to flatten the file system hierarchy for the user.

1 is clearly useful because we need to protect our code from bleeding effects from the rest of the application (and vice versa). A language with only global constructs may be what some of us started programming on, but it’s not desirable in any way today.

2 may not be always reasonably worth the trouble (jQuery is doing fine with its global plug-in namespace), but we still need it in many cases. One should note however that globally unique names are not the only possible implementation. In fact, they are a rather extreme solution. What we really care about is collision prevention within our application. What happens outside is irrelevant.

3 is, more than anything, an aesthetical choice. A common convention has been to encode the whole pedigree of the code into the namespace. Come to think about it, we never think we need to import “Microsoft.SqlServer.Management.Smo.Agent” and that would be very hard to remember. What we want to do is bring nHibernate into our app.

And this is precisely what you’ll do with modern package managers and module loaders. I want to take the specific example of RequireJS, which is commonly used with Node.

Here is how you import a module with RequireJS: 

var http = require("http");

This is of course importing a HTTP stack module into the code. There is no noise here. Let’s break this down.

Scope (1) is provided by the one scoping mechanism in JavaScript: the closure surrounding the module’s code. Whatever scoping mechanism is provided by the language would be fine here.

Collision prevention (2) is very elegantly handled. Whereas relocating is an afterthought, and an exceptional measure with namespaces, it is here on the frontline. You always relocate, using an extremely familiar pattern: variable assignment. We are very much used to managing our local variable names and any possible collision will get solved very easily by picking a different name.

Wait a minute, I hear some of you say. This is only taking care of collisions on the client-side, on the left of that assignment. What if I have two libraries with the name “http”? Well, You can better qualify the path to the module, which is what the require parameter really is.

As for hierarchical organization, you don’t really want that, do you?

RequireJS’ module pattern does elegantly cover the bases that namespaces used to cover, but it also promotes additional good practices.

First, it promotes usage of self-contained, single responsibility units of code through the closure-based, stricter scoping mechanism. Namespaces are somewhat more porous, as using/import statements can be used bi-directionally, which leads us to my second point…

Sane dependency graphs are easier to achieve and sustain with such a structure. With namespaces, it is easy to construct dependency cycles (that’s bad, mmkay?). With this pattern, the equivalent would be to build mega-components, which are an easier problem to spot than a decay into inter-dependent namespaces, for which you need specialized tools.

I really like this pattern very much, and I would like to see more environments implement it. One could argue that dependency injection has some commonalities with this for example. What do you think? This is the half-baked result of some morning shower reflections, and I’d love to read your thoughts about it. What am I missing?

53 Comments

  • So... how's this different from:

    var http = new Some.Long.Namespace.Class();
    http.KeepItIsolated();

    What am I missing?

  • @Peter: first, the http variable points to the module, not to an instance of a class. Second, there is no point in having a deep namespace structure. Third, the module's file can be physically moved around in case of a conflict, instead of having to refactor the code to change namespaces.
    But out of curiosity, what is KeepItIsolated supposed to do?

  • @Peter: exactly.

  • Isn't that the same idea as what Python has been doing for years?

  • @ludovic: not exactly but close. The Python syntax is a lot more convoluted and obscure in my opinion. I never claimed that was a JavaScript innovation however, which is why I presented it as an example.

  • I don't feel like writing a complete blog entry in response, but a module is distinct from a namespace. A module provides the unit of distribution and versioning, while a namespace is a code organisational feature primarily (collision prevention is only secondary).

    I think (as usual) the CLR and C# get it right, the rest are just hacks.

  • About "there is no point in having a deep namespace structure" - please try to refactor .NET Framework without namespaces at least 3-4 levels deep.. :)

    Sure, for classes used just inside a project and not used by other projects, namespaces are not really necessary, but as soon as you start using libraries developed by various companies in the same project, namespaces are necessary to avoid collisions.

    Back to your example: even in JS, what do you do when you want to use 2 different classes, at the same time, from two different vendors, that happen to have the same name?
    You either specify the location of the file when defining some kind of "alias", or a simulated namespace, the result is the same..

  • @Jeroen: of course a module is distinct from a namespace. Did I imply otherwise?

  • @Tudor: I wrote part of the .NET framework (a very small part of course), and I don't see why it couldn't or shouldn't be done. If you look outside of .NET and Java, you'll see non-trivial examples. Also, even if I personally don't like deep hierarchies myself, this is a rather orthogonal concern as the RequireJS pattern allows for it (even if it doesn't encourage it).
    Namespaces are not necessary to prevent collisions. I'm not sure you read the post because I addressed that, as well as how to have two classes (classes in JS? ew) with the same name. They would just be under different modules. It's only when the module names are the same (highly unlikely if the name is good) that you need to move them around. And no, specifying the location of a file and changing code are not the same thing. You'll see the difference when you need to update your dependencies.

  • The beauty of requireJS (more specifically AMD), is that it actively promotes producing clean, modular code.

    Baking in a reference to a module through and explicit namespace reference hampers testability and couples your code together in a way practically guarantees that you'll produce a big ball of mud.

    Having a flexible system for service location gives you the freedom to compose your application from reusable parts and easily substitute components when required.

  • @Bertrand: you *did* talk about something that "happened fairly recently", although Python predates C# by 10 years :)

    Python's syntax is both more and less convoluted I find. For the most common case, it's a lot simpler: "import foo" instead of "var foo = require('foo')", which I'd argue is the right thing to do (have the simplest syntax possible for the most common case).

    For something more similar to RequireJS, which incidentally is also just for the advanced case where you don't know, at compile time, what's the name of the module you want to import, you go "foo = __import__('bar')", which is kinda weird but I guess it follows Python's naming convention of double-underscored "magic" stuff. It's also the only way I know of to import something as a different name -- which is more natural to do in RequireJS as you just change the name of the variable. But basically it's all syntactic difference -- some simpler, some more verbose.

    The main difference is that modules (and functions imported via "from... import...") are imported as attributes of the current module, instead of local variables as in RequireJS. It's interesting because it means you can use the same reflection mechanism as when reflecting classes and objects.

  • @ludovic: nitpicker. Nobody was paying attention back then :D The "something" is that package managers and module loaders functioning on these ideas are now getting very popular.

  • @Master man: thanks for your nice and thoughtful feedback. I don't use WCF, but it doesn't matter as you completely missed the point.

  • Bertrand, a huge number of programmers get a lot of value from the way you freely share your work and ideas - you've helped me out many times with your postings.

  • if namespace wants to grow
    1) it can take the responsibility for visibility(public, protected, internal, private, get, set).
    2) multicore responsibility(pure/immutability/async etc...)

  • While the node/package manager way of doing it is convenient, it's certainly evil at its best. For years I've been told to avoid magic in PHP, only to see it happen everywhere in node. One reason I can think of in doing this is the fact that there will be awful issues when there are naming collisions, possibly even being the cause of security exploits.

    Let's see a real world example shall we?

    LoadLibrary('user32.dll');

    ^ does that look familiar? Head over to DLL Hijacking if not...

  • @Bertrand: yep, you know me :) I guess you're right that it's getting popular lately (although I'd argue the popularity of the concept itself didn't change much, especially compared to the popularity of the languages using it). I never really thought about it until your post, which I guess is how you know a blog post was valuable.

    I'm not totally convinced about your dependency-creep argument, though. The unit of dependency in environments like .NET is the assembly -- not the namespace. In JS or Python, what you do, as far as I can tell, is import/require the equivalent of the whole assembly, as if it only had one namespace in it.

    Their "assemblies", as a result, are much smaller. Something like "System.Net", which contains everything from sockets to HTTP stuff to email stuff, would be broken up into a dozen different packages/modules.

    It's probably true that it makes it easier to check that there's no unwanted dependencies between them, as opposed to the "freedom" you get inside one assembly... but it seems to me that it touches a lot of more important things than namespaces: we're talking about a fundamental difference in how packages/modules/assemblies/whatever are distributed, compiled/JIT'ed/interpreted, cached, etc.

    Basically, it wouldn't do you any good to, say, add syntactic sugar to C# 5.0 so that you can do "var sysnet = use("System.Net");". I guess you were hinting at that already, but it wasn't explicitly explained. You made me think about things. My head hurts now. I hope you're happy.

  • I have to disagree, your example using require.js actually uses namespaces, in a very real way.

    1. Everything in that module is scoped by that name.
    2. Collision prevention occurs by access being scoped to the name.
    3. If your module exposes other names, those can form a hierarchy.

    The difference here is that the resolution occurs dynamically rather than statically, that's what enables scenarios like substitutability. In a dynamically typed language that makes sense. Attempt that in a statically-typed language and there are many pitfalls.

    The Import statement used in various languages for this purpose breaks the dynamic resolution - allowing dependencies and reducing substitutabily. Again, this makes some sense in a static language (where the type system will require some of these dependencies, which can be mitigated by facilities such as interfaces), but in dynamic languages like Python is really out-of-place.

    Of course most Smalltalk environments have had this for years - where change sets can be loaded into an image, and all name resolution is dynamic. As usual, the mainstream still has many lessons to learn from that wonder of a language.

  • "As for hierarchical organization, you don’t really want that, do you?"

    I do. That's basically how my brain thinks. I guess I'm weird. I hate "flat" namespaces, even when they are by design for my own ease.

  • You're not providing for the create instance for multiple users of the same site. Without namespaces this will create overflow resolution issues and bring down your server.

  • so really you just load an "end level Namespace" into a variable to prevent conflicts vs using a namespace

    instead of
    background = system.drawing.color.red

    you are doing
    var x = Color
    background = x.Red

    Just adding complexity to your code really. cause I for example decide I want Red to mean more than just color. mtcoder.drawing.RowColor.Red sets a whole row in a grid red

    var y =RowColor
    accountingRow = y.Red

    I personally am good to go. I hand this code over and the guy sees


    var x = Color
    var y =RowColor


    background = x.Red
    accountingRow = y.Red

    Then has to go looking for x and y declarations to determine what they are going. But we know better to use unmeaningful variable names right? To prevent this from happening.

    var DrawColor = Color
    var RowColor = RowColor

    Now we get
    background = DrawColor.Red
    accountingRow = RowColor.Red or I could skip the whole var declarations all together and just go

    background = DrawColor.Red
    accountingRow = RowColor.Red

    Wait.... what? looks similar

  • The module concept is familiar to me from my days with Lua. But I don't see much practical difference between

    var io = require("io")
    var entities = require("engine/entities")

    and

    using IO = System.IO;
    using Entities = MyProject.Engine.Entities;

    In terms of organization you're just pushing the burden of your naming out to the filesystem, or into your module names themselves.

  • Where did you get that image?!

  • Dude, yeah, think before you blog your thoughts. Once you post it, it becomes not just best practice, but the only practice. Leaving internet now ... too dangerous.

  • Call them namespaces, packages or whatever, in a large project you absolutely need a hierarchy of nested namespaces, if you're not masochistic. It's not a technical necessity, and it's not related to the _object_ structure, it's just a way to deal with a human's difficulty in comprehending long lists. Groking trees 3-4-5 levels deep, but which only have a handful of sub-nodes in each tree node, is much easier.

  • I'm not sure I get the usage part here, but does that mean all calls into http have to use the prefix http.foo()?

    If so, one thing I don't like about this is the http variable is user chosen. With names like LeRoyJsonParser, some will abbreviate it LRJP, or lrjp, or ljp etc. Then that code is harder to read and move around. I'm not saying there is never a problem with people knowing they need to import System.Drawing.Drawing2D on a web snippet, but at least tooling can help there. And once you do, everyone's code looks the same (other than the rare case where you need aliasing, but that is the always case here).

    Of course I may not be understanding how it is used, please disregard if so. Thanks for the post, always good to challenge our habits :).

  • I agree that most people are more comfortable with non-hierarchical structures, like throwing all of your documents on the Desktop or a non-organized My Documents. But I disagree that this is a mindset developers should strive for. I always thought that the ability to organize small components of a large task hierarchically is an important skill for a developer.

    Have you ever written about your dislike of deep hierarchies before? I would be interested in reading those opinions, because this is the first time I have ever heard a developer/engineer say that.

  • Not sure I agree with this post.

    First off it seems to be the same as namespaces except you are defining it in a different way.

    Secondly you are introducing strings rather than strongly typing stuff.

    Thirdly having the deep namespaces is a lot easier as you can guess your way down to it - System.[AutoComplete DropDown]Text.[AutoComplete DropDown]RegularExpression

    Fourthly the paths can change and there isn't any reason to hard code it into the system every time you want to reference it. Why not just let the strongly typed namespace system abstract this away in a consistent manner? Just think of the tutorial writers if nothing else - don't give us another thing that can blow up in the n00bs faces! :)

  • @Christian: orthogonal concern. A project reference is no different and has the same issues. We use signatures to work around it, which could also be done with a package management API.

    @"Master Man": you're still spectacularly missing the point. I'm not your dude. You're a troll and I'm not interested in your opinion. Don't bother answering, it will be treated as spam.

    @John: what do you mean?

    @Justin: one of the differences, mentioned in the post, is that using a namespace locally fuses that namespace and your local namespace, and that can happen bi-laterally (A can use B while B uses A as well), which makes it easier to create dependency cycles.

    @Larry: from some funny blog. If somebody knows the credits for this work, I would love to include them.

    @Anonymous coward: I've managed some pretty large projects and I disagree to an extent. First, I'm not arguing against structuring your code, but I prefer meaningful constructs rather than pure abstract containers, such as application/module/folder/class/method. The hierarchy is still there but not just for the sake of the hierarchy. For example, in Orchard, we have module, under which you have folders such as controllers, drivers, etc., and then classes. There is little need for hierarchical names at the module level (it can be called http rather than System.Net.Http). In any case, it's a little unfortunate that the discussion would focus on hierarchies because the pattern I'm showing here can accommodate for hierarchies as well. I understand I'm responsible for having presented things that way.

    @Branco: yes, but that is not the same thing. See my answer to Justin. I don't understand your concern with polluting the "global" local namespace. Aren't you doing the same thing when you do dependency injection for example?

    To all: yes, this pattern (does it have a name by the way?) is very close to namespaces, of course. If it's going to replace namespaces, it has to cover the same requirements, so it is going to appear very close. It's an incremental improvement. You need to focus on the differences instead of trying to show similarities, which are clear and intentional.

  • @ludovic: yes, this pattern encourages smaller packages, with saner dependency graphs. Absolutely. That's a good thing. Of course, this works better with dynamic languages where the cost of importing something is low compared to .NET for example where there is an unfortunate performance requirement to have less and bigger assemblies rather than lots of small ones. As a matter of facts we have to manage this conflict of interests in Orchard. It's not a simple problem.

  • I basically agree with the author. But I would highlight two distinctions that define these and other possible alternatives.

    (a) Who picks the name (of the encapsulation unit)? The module or the user of the module?

    (b) Is the encapsulation unit identified by a variable, or by a static name?

    In most namespace systems, the module picks the name(s) and uses a static name. In the article's require example, the user of the module picks the name ('http') and uses a variable. The other combinations are also possible.

    I think (a) is the key point to the author's arguments. I think there are trade-offs. E.g., When modules pick the name, collisions are still theoretically possible. But standardizing on the same name in all code that a particular module can help with readability. Multiple sibling namespaces can be declared by a module, but a single namespace is imposed when the user names it.

    Distinction (b) is not central to his argument, but is relevant to the discussion. The use of variables means you can dynamically swap which module a namespace refers to (I'm not sure what use that would be). In a compiled language, the use of static names can enable compilers to make substantial optimizations.

  • @Rob: I agree, and in fact I think that most of what you're saying is in the post. I've also hinted at dependency injection as a similar concept with statically-typed languages. You're right that there is still much to dig out from Smalltalk.

    @Robin: what you don't like is what I like. If a developer doesn't know how to name his variables, that's a problem no matter what.

    To all who are complaining about the "magic strings", get used to it. Dynamic languages are all about magic strings. In foo.bar(), bar is a magic string, as it can be replaced, in JavaScript, by foo["bar"](). With good tooling and testing there is no problem here.

  • @Lonnie: in the case or RequireJS, the file name for the module is chosen by the module author, but the application developer can choose to place this file in a different folder (without changing code or file name). The scoping mechanism in itself is an anonymous function. On the consumer side, the name is chosen freely.

    One more thing about hierarchies: with namespaces, they are necessary, whereas with this pattern they are optional. More freedom.

  • @ludovic, you could do "import bar as foo" instead of "foo = __import__('bar')"

  • Poppycock. The context of this article is very narrow.

  • All wrong. Namespaces are about nomenclature (naming and hierarchy) and semantics, not about runtime really as much. What you describe is a poor technique in even poorer evnironment in an obsoloete lanaguage.

  • @Querulant: JavaScript is an obsolete language? That's amusing. Anyway, in any dynamic language, the runtime is all there is. How are namespaces about semantics? Can you explain how this is a poor technique?

  • @Ghislain yes, I realized that later :)

  • "which is why the Windows explorer for example has tried in a few different ways to flatten the file system hierarchy for the user. "

    Windows Explorer's latest version which uses the Ribbon technology is not flat. Anything but flat. Instead of menus, drop-downs and slide-offs, which are only tied to the hierarchy, the hierarchy instead ties to ordinary language words associated with a whole set of controls and not just Button, Dialog and Edit box.

    My bet is namespace exclusivity will in the long run have to be explicitly tied to regular language structures like Windows Explorer's Ribbon (and Word and PowerPoint, etc.), but with P2P software behind the scenes that resolves the context. Currently, it is Microsoft that RESOLVES any ambiguity in, for example, Ribbon words and controls, but there is no reason why this responsibility can't be (synchronously) spread around in an ideal world.

  • There are standard naming conventions for Javascript variables? Someone should tell the world wide web ; ).

  • Yup, javascript is a terrible *and* obsolete language. There just isn't any better alternative in the browsers. The fact that it has functional features does not make it any better actually and number of people using it does not mean the language is good. It's there just like there was Cobol, Fortan and BASIC in certain environment at certain time.
    Semantics: how do you structure complex stuff so that other can understand it ? How do you make sure other code inside 'packages' are able to lookup the right stuff in other packages ? How do you manage evolution of packages which are out of your hand ?
    The technique is poor because the javascript is missing such important features as namespaces, not as in your example. It's ok the way you do it, but it's naive (as in Hello World example) the complex stuff will remain complex *and* others will emulate namespaces in different way in the same environment -- see ExtJS as example.
    So will the namespaces go away ? Hardly.

    And just one more note: the fact javascript has 'all there is in runtime' is thinking inside the javascript box. Try to think out of the box: why aren't there namespaces in javascript ? :-D

  • @rtischer: I said "flatten", the result of which is not necessarily completely "flat", and the ribbon is a actually a lot flatter than the menus were. The menus were hierarchical by nature, whereas the ribbon is just organized.

    @robin: that's not what I said, but yes, Camel-casing is the convention.

  • Cool, I'm glad we're able to amuse each other.

  • @ludovic: In python you can do "import foo as bar" instead of "bar = __import__("foo")".

  • I think the main difference is that this pattern is consumer-oriented (i.e. you expose a simpler API via "http" module) vs extender-oriented (heavy namespaces and millions of classes, abstracts, virtuals, etc.).

    VB's My thing was an attempt, I think, to bring some of that simplification to code reuse. And you can see how .NET in general mixes the two concerns annoyingly (i.e. System.IO.File has a lot of static methods which are just usability facades over the "real" APIs).

    I think you're on to something with this. Maybe there is a better way to expose to the public/consumer code something that is simplified and different than the extender/advanced API (namespaces & friends).

    I've seen this dual approach taken by projects like xUnit, where the user-facing API is simply under Xunit, whereas the "real" underlying APIs are under something like Xunit.Framework or Xunit.Sdk or the like.

  • What about the fact that editor intellisense would be a less useful on those occasions where you are looking for a method but can't quite remember it or you are not sure what it might be called. Organisation can help.

  • @G: Node code is not less organized. Deep hierarchies are not the only ways to organize things.

    In this case, if you are looking for something http related, you'll type "http" and immediately get relevant answers, instead of having to guess that you need to go through "System", then "Net". Really, I think your arguments play exactly against the point you are trying to make.

  • A few comments / questions:

    Would you advocate for .net programmers to use shallow namespace hierarchies and aliased using statements? If not then why not?

    I find that I really like the pattern you describe in dynamic languages, but that the benefits are less compelling for something like Java or C# because a good editor will let me instantly discover which referenced code classes come from which modules. In fact, I think the point you made about dependency injection is spot on. I would argue that the pattern you describe is actually closer to DR than to namespaces for statically typed languages.

    In terms of moving things around on the file system or further qualifying a module path in RequireJS to prevent collisions, how does this work with third party modules that require other third party modules (seems like this problem should be common if modules are small)?

    Very interesting article!

  • @Mike: yes, I would advocate for relatively shallow namespaces in .NET that reflect actual structure rather than hierarchical organization for the sake of it. Look at nHibernate for example: you have the top-level nHibernate namespace, then some high-level modules and then the classes, in most places.
    Aliasing on the other hand is only useful in .NET in case of name conflict. I would avoid it otherwise as it won't add much value. It looks the same as what I'm describing here but it really isn't: a closer equivalent would be dependency injection.
    I agree that it's more compelling in dynamic languages. Maybe I should do a follow-up post on how this is similar to dependency injection.
    On deep dependencies, there is a resolution algorithm that will take care of that.

  • @Querlent: "Semantics: how do you structure complex stuff so that other can understand it ? How do you make sure other code inside 'packages' are able to lookup the right stuff in other packages ? How do you manage evolution of packages which are out of your hand ?"

    I really like your questions. My answer to these questions was to resort to an ISO standard for producing computer tractable contexts (SGML). (I was on the original committee). No room for international misunderstanding there. HTML is just one of these contexts that SGML can produce, which the whole world seems to be infatuated with. JS is merely an after-thought code technology whose functions are randomly woven into the simplistic HTML structure. And namespaces in JS would be even more ridiculous since it is a construct that tries to go back and do the job of the overlying context creator SGML. Referring to the SGML->HTML->JS->NS paradigm mess, I am always astounded by the lack of basic linguistic theory that computer scientists continually exhibit.

  • What a stupid idea!
    Namespaces are perfectly managed by "using" directive (in C#) and not only separate classes, but also NOT ANNOYING us with specifying namespace every time you need that class - you write clean code using classes only and "usings" in a top of file, that's it! What's NEW you invented here? "using Very.Long.Namespace = VLN"?

  • @Vincent: talk about MISSING THE POINT.

  • Namespaces are such a simple thing. I don't see any way of getting a rid of them either unless the compiler doesn't require them unless there is the possibility that the type could be multiples. That could be a good enhancement.

Comments have been disabled for this content.