tags:

views:

90

answers:

4

Assuming namespace A2 is nested within namespace A1, then A2 is a member of enclosing A1. But members of A2 ( thus types declared within A2 ) are not members of A1.

a) What exactly is meant by members of A2 not being members of A1? In other words, what would be different if they were also members of A1? Perhaps that inside A1 we wouldn’t have to use fully qualified name for types in defined in A2?

b) What exactly is it meant by namespace A2 being a member of A1?

BTW - I do understand namespaces, I'm just confused by the terminology used by my book ( namely, A2 being a member of A1 etc )

thanx

EDIT

1) So essentially A2 being a member of A1 is the reason why inside A1 we don't have to specify A1. prefix when referencing types declared in A2:

namespace A1
{
    class Program
    {
        static void Main(string[] args)
        {
            A2.classA2 a2= A2.classA2(); //here we don't need to include A1.
                                           prefix
        }
    }

    namespace A2
    {
       class classA2 { }
    }
}

2) The following is defined within assembly asmLibrary.dll

namespace A
{
    public class A1{}


    namespace B
    {
        public class B1{}
    }
}

The following application App1 also has a reference to assembly asmLibrary.dll:

namespace A
{
    class Program
    {
        static void Main(string[] args)
        {
            B.B1 instanceB1 = new B.B1();
        }
    }
}

The following application App2 has a reference to assembly asmLibrary.dll:

using A;
namespace ConsoleApplication2
{
    class Program
    {
        static void Main(string[] args)
        {
            A.B.B1 bInstance = new A.B.B1(); 

            A1 a1 = new A1();
        }
    }
}

a) When we tried to declare in App2 an instance of A.B.B1, we needed to specify fully qualified name of the type. But with App1 we were allowed to specify the type via B.B1. Thus why were we allowed to ommit the A. prefix inside App1, but not inside App2 ( App2 has a using A; directive, so its behaviour should be identical to that of App1 )?

b) Also, if namespace B is a member of namespace A, shouldn't then App2 allow us to declare a type A.B.B1 using B.B1 instanceB1 = new B.B1(); syntax?!

+1  A: 

Members of A2 are members of A2 - "the buck stops there". If the A1 contained definitions of the members of A2 then nothing changes - whichever way you'll need to reference these members as A1.member and members of A2 as A1.A2.member - unless you have using statements in which case you'll need to tread carefully if you want to avoid compiler errors.

Will A
+3  A: 
Henk Holterman
So esentially saying A2 is a member of A1 simply means that inside A1 we don't have to specify A1. prefix when referencing types declared in A2?
flockofcode
Here's some extra thoughts: 1. Namespaces are used to organize your classes in logical collections. To further organize things you can 'nest' namespaces: `My.Namespace` and `My.Namespace.Nested`. However this has no impact on a given type at runtime. At runtime the namespace is just a string that may or may not have a `.` in it. 2. What namespaces do affect is type name resolution during compilation, which is based on (in simplification) the namespace of the current type and the `using` statements in your file. Henk's example illustrates this quite well.
marcind
@flockofcode: Yes. A2 and C1 are both members of A1 and much of the same rules apply.
Henk Holterman
»@flockofcode: Yes. A2 and C1 are both members of A1 and much of the same rules apply.«But according to my book A2 is a member of A1, while C1 is not a member of A1
flockofcode
@flockofcode: Why wouldn't C1 be a member of A1?
Henk Holterman
As fara s i understand, if C1 was a also member of A1, then we would be able to also reference C1 via A1.C1 and not just via A1.A2.C1
flockofcode
@flockofcode, I think you should read it again (-: A1.C1 is correct.
Henk Holterman
Ups, I thought C1 was declared within A2. Anyways, if you read the edit I made in my original post, you'll notice that namespaces App2 display some different behaviour than namespaces in your example and App1. Any idea why that is?
flockofcode
According to the link you've provided using directive imports types contained in A, but it doesn't import namespaces nested in A. Anyways, thank you for your help
flockofcode
+1  A: 
  • What exactly is it meant by namespace A2 being a member of A1?

The meaning of member is covered in the C# specification, section 3.4:

Members

Namespaces and types have members. The members of an entity are generally available through the use of a qualified name that starts with a reference to the entity, followed by a “.” token, followed by the name of the member.

Members of a type are either declared in the type declaration or inherited from the base class of the type. [...]

The definition of "namespace members" is given section 3.4.1:

Namespace members

[...]

Namespaces and types declared within a namespace are members of that namespace.

  • What exactly is meant by members of A2 not being members of A1?

It means that just because A1.A2.Foo works, it doesn't imply that A1.Foo also works.

Mark Byers
Would you be willing to help me a bit more? Namely I've edited my original post
flockofcode
+1  A: 

As far as I understand, IL has no concept of namespaces. The compiler appends namespace names and type names to compose longer full names; for example, class Customer in namespace MyCompany.MyProduct will be rendered as something like MyCompany$MyProduct$Customer when compiled into IL. To the IL virtual machine, that is a type name; the fact that it contains $ signs is irrelevant.

From that fact you can derive your own conclusions. :-)

CesarGon