Merits of Namepsaces/Packages

Question

Some programming languages (e.g. Java and C++) have language features called "packages" or "namespaces". How useful is it really to have namespaces? It is possible to mark functions and classes as belonging to some particular library without using such a language feature, like the SDL does (e.g. SDL_BlitSurface()). Are namespaces not helpful enough to be worth having? Are they useful in libraries but not in applications? Are they useful everywhere except for in small projects? Thoughts?

Answer 1

Aren't name prefixes the same thing as namespacing, except that it's done in a way that is less useful and more difficult to read/parse? Doesn't the question answer itself?

Answer 2

Most (all?) languages with namespaces tend to be object oriented. Many times a human readable name for a type is appropriate, even though there are multiple incompatible implementations. (this brings up other issues on object oriented reuse, but that's not what this question is about). For instance, in Java you have a Timer that is used for background UI tasks, and a Timer that is used for background application (not tied to AWT/Swing) tasks. The namespace allows you to have these same-named objects living in different sub-APIs.

The reason that namespaces came into existence had to do with the unreasonable task of anticipating what other developers will name their objects. C++ introduced the concept (or at least was the first language I was exposed to with the concept), and it was helpful even though there were no guidelines on best use practices. Java adapted the concept and added some "best practices" that included your company name in the namespace. That way you only had to worry about your own company.

Prefixing can become pretty messy. When do you apply it? When do you not apply it? Do structures/classes/global methods get the prefix? What about methods? What about properties in the struct. I've seen all of these things in code, although thankfully not all at once. Namespaces provides some predictability to all of these questions, and makes it a language feature rather than a personal "best practice".

Answer 3

I think that namespaces are a great idea. They help prevent naming conflicts by limiting the scope of a name. In Java packages, the suggested package naming convention is based on domain names, which should be unique, which help prevent naming conflicts over custom libraries. Overall, they make naming a bit more unique in the broad sense, while still allowing the programmer a good bit more freedom in naming his pieces without having to follow some obscure naming convention.

Answer 4

Namespaces/Modules/Packages are useful for avoiding name conflicts. So is name prefixing but namespaces have the added convenience of being able to import symbols into the current namespace so that you don't have to bother with the whole Namespace::*.

Some languages (like Python) extend this ability by allowing you to import only specific symbols into your current module or import symbols as a different name. This is useful if you are only interested in a few classes/functions/constants or if some of the symbols conflict with symbols in your namespace but some don't.

Some languages (like Ruby) allow you to include the methods of a module into your class. This is useful for polymorphism and generics. For example, if you have several classes that have iterators that act in the same way, you can mix methods in to all of these classes from a separate module that provides methods to sort and filter the data in the object. This allows has a relationships as well as is a (inheritance) relationships .