Coffeehouse Thread

7 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Name Spaces

Back to Forum: Coffeehouse
  • User profile image
    Quiddy Biddy

    Hi all,

    After the prompt reply to my last post i am eager to re-use this new found resource that is 'the forum'.

    Can someone explain to me what a 'namespace' is?

    Is it something you use in VS2005+ to allow you to logically group types?

    Cheers

    Quiddy Biddy

  • User profile image
    Sven Groot

    Basically the idea is something like this: let's say you're developing a program and you have a class named Foo (why? because everybody names their classes Foo in examples). Then at some point you discover that you really need fabulous library X for your program, but unfortunately it turns out they also have a class named Foo.

    Conundrum! This name collision means that one of you is going to have to change the name, and if you don't have the source to library X it's probably going to be you. In the olden days this was the case, if you're developing for Windows using C you better not want to name a function "CreateWindow" because unfortunately that name (and about a 100,000 more) is already taken by the Win32 API.

    The obvious solution to this is to reduce the chances of name collision occurring which you can do by making your type names really long. But unfortunately that also makes them a PITA to use. Instead, namespaces are introduced. Namespaces are actually just another way to make your type names longer, but they have the advantage that you can import them (e.g. "using System.Xml;" in C#) so you don't have to type the full name all the time.

    Furthermore, by following certain conventions for namespace names (such as starting them with MyCompanyName.MyProductName) you reduce the chance of name collisions almost to zero.

    Namespaces are not exactly new. C++ has had them since somewhere in the mid-90s. Java has them, and .Net has also had them since .Net 1.0 and Visual Studio 2002.

    And yes, one of the convenient side effects of this is that it also allows you to nicely group your types, which if you have a bloody lot of them can make everything a lot easier to grasp.

  • User profile image
    Quiddy Biddy

    Ok so its more a logical grouping? For the purpose of, not only human sanity, but CLR resolution at run-time?

    ??

  • User profile image
    Sven Groot

    Name resolution is done not at run time, but at compile time. In the compiled code names are no longer important.

    In the CLR it's slightly different (than e.g. C++) since the VB or C# or whatever code is compiled to intermediate language (IL) first, which is then Just-In Time (JIT) compiled at runtime. The IL code still contains the names (actually it contains numerical atoms which map to a table in the assembly metadata which contains the names but let's not overcomplicate things).

    To the compiler (whether it be the VB/C# compiler or the JIT compiler), a name is just a string. All it sees is "System.Xml.XmlDocument", it doesn't care that the System.Xml part is a namespace. If it sees "XmlDocument" (without a namespace qualification) it needs to prepend all imported namespaces at that point in the source to that name to create the fully qualified name until it finds a matching type (and that cannot happen with the JIT; all names at the JIT stage are fully qualified).

    So namespaces actually make life harder on the compiler. To the CLR itself it makes no difference (all names are fully qualified at that point).

    They are purely for the benefit of the programmer. To help organize your program, and to help prevent name collisions. That's all.

  • User profile image
    wkempf

    Quiddy Biddy wrote:
    Ok so its more a logical grouping? For the purpose of, not only human sanity, but CLR resolution at run-time?

    ??


    I'm reading "Framework Design Guidelines" right now, and they discuss this topic quite a bit.  In .NET, namespaces aren't really about preventing name collisions.  You can't have a name collision across assemblies, because .NET uses "strong naming" which makes this impossible.  So the only collisions that could occur are within an assembly, and if you have a collision there you probably have a bigger problem with your design (i.e. you shouldn't being reusing names just because they're in different namespaces).  So the main purpose of namespace, in .NET at least, is for logical organizations.

  • User profile image
    JChung2006

    Sven Groot wrote:
    Name resolution is done not at run time, but at compile time. In the compiled code names are no longer important.

    This isn't entirely true, due to things like reflective programming (System.Reflections) and late binding (VB.NET), but for the purposes of this thread, it is true enough.

  • User profile image
    ScanIAm

    wkempf wrote:
    
    Quiddy Biddy wrote:
    Ok so its more a logical grouping? For the purpose of, not only human sanity, but CLR resolution at run-time?

    ??


    I'm reading "Framework Design Guidelines" right now, and they discuss this topic quite a bit.  In .NET, namespaces aren't really about preventing name collisions.  You can't have a name collision across assemblies, because .NET uses "strong naming" which makes this impossible. 

    Not always true, but it takes some odd conditions to make it fail. 

    If you reuse an object name and fail to put the 'using <mylibraryname>;' statement at the top of your class, you are going to be very disappointed when you try to compile.

    wkempf wrote:

    So the only collisions that could occur are within an assembly, and if you have a collision there you probably have a bigger problem with your design (i.e. you shouldn't being reusing names just because they're in different namespaces).  So the main purpose of namespace, in .NET at least, is for logical organizations.


    It certainly seems that way, but again, there are exceptions.

    I'm working on an application that has 2 different data sources.  One is SQLServer, and the other is a mainframe.  There are a number of cases where I'll need and want to reuse member function names (but not neccessarily objects) between 2 different namespaces.  In reality, I just shoved them both in the same namespace and reference them uniqely by their class name, but it might be useful, no?

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.