No formal essay here, just a mishmash of thoughts:

• First, we all know that collisions are too easy without namespacing.
• For fear that namespaces themselves would collide, Java started including domain names. But this gets deep and annoying.
• XML thought "best of both worlds" by full URIs with common shorthand one-word names, but still a pain.
• Sometimes projects move. Do you rename the domain part (meta namespace) to keep clean or just keep old package names for compatibility?
• The project really is best thought of as that project.
• Usually best for projects just to have different base names. "Not this blah but that blah" is no fun. Usually better to rename a project even if not forced.
• Requires unusual names sometimes, but we often try to do that anyway.
• In C, namespacing (e.g., manually prefixing "gtk") is such a pain. And definitely not worth more than one level deep. But practice shows that the one level is usually enough.
• JavaScript libraries also usually get by on just one namespace deep ("dojo", "jQuery", "Ext") because more is a pain and a single one works.
• Fan pods keep the one level simple names but don't require the inconsistency and manual pain of C.
• For example, C's lack of language feature leads to inconsistency like gtk_whatever() vs. GtkWhatever and is part of why I like easy automatic namespacing (including my stated opinions on facets/symbols). Why not just get things consistent and "for free".
• Also, awesome not having to say pod blah at the top of each file (Java like) or worse namespace blah { ... } around the whole file (like most other languages).
• And internal vs. public classes makes a lot more sense without subpackages. Presumably this avoids the need for complications like "super packages" as we're seeing in the upcoming Java Module feature (and in OSGi and such like).
• Module file name matching namespace name is super duper sweet. (I feel like I'm rolling the dice sometimes in Ruby to guess gem name vs. require file name vs. module name.)

Summary: Fan pod namespacing rocks. Felt like sharing my opinion.

I like pods too, but I worry that one level won't be sufficient for larger sourcebases. The possibility for name clashes seems quite high, especially given that some pods will be external to your company, or in other departments.

Do we have a story on how to handle larger sourcebases?

Here's my story. We seem to agree that public projects are unlikely to collide. I would recommend that internal code be prefixed by company name. For example, instead of "util", call it "companyUtil" or "company_util". I think I prefer the former, but either beats needing to worry about nested names (by a long shot). That's my opinion.

As Tom said, that should be handled just like Java by prefixing your company name, project name, or some other unique identifier (camel case though, not underscore).

Fan pod namespacing rocks

Thanks! I think it is pretty sweet myself.

I like pods too, but I worry that one level won't be sufficient for larger sourcebases.

From Structure Pod:

Pods are the top of Fan's namespace as well as the unit of deployment. A pod's name is globally unique and is used to organize the top level of Fan's namespace. Pod names are similar to Java packages or C# namespaces. To guarantee uniqueness, organizations should prefix their pod names using reverse DNS names in camel case. For example a company which owns "acme.com" and wishes to create a pod called "Foo" would name the pod "comAcmeFoo".

Would it be possible to change this rule to dot separated? The result could still be treated as a single string rather than a directory hierarchy.

It just seems that "com.acme.foo" is more understood and recognised than "comAcmeFoo".

Would it be possible to change this rule to dot separated

Not really because then we can't treat it as a single identifier in the grammar. Although I'm open to other suggestions.

I loves it like it is. Saying comAcmeFoo is different than Java, but it doesn't really require more typing. It also helps to think more from a cooperating modules perspective. And it's also simpler. And filename friendly.

I feel that behind nested namespaces lies madness.

Speaking of madness, here's a nice example from current Java 7 plans:

There are two different ways to use the module keyword to declare module membership:

1) To declare module membership in the individual source file of a class (recommended):

// hello/HelloWorld.java
module hello;
package hello;

public class HelloWorld {
    ....
}

I really don't want to ever have to do that. And I really don't care if the IDE does it for me.

One thing is for sure, modularity is something to design in from the start - not to try to patch on a decade later. I can just imagine the pain that taking module as an keyword is going to cause (unless they make it context sensitive).

That's exactly why all languages rot. People try to apply features in patchwork fashion, in a way that doesn't disrupt the existing codebase or grammar. As a result, the languages start looking like a hodge-podge collection of different ideas.

C++, now Java.