By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,205 Members | 1,030 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,205 IT Pros & Developers. It's quick & easy.

Difference between namespace { using System; } vs. using System; namespace {}

P: n/a
Can someone tell me the difference in terms of actual implications using:
namespace MyNamespace {
using System;

class MyClass {...}
}

vs.

using System;
namespace MyNamespace {

class MyClass {...}
}

are? There's a framework recommendation that the former be used (and some
ASP.Net templates create classes like this), but I use the latter. I've
tried both but could never determine a difference between the two, so I'm
unsure why there's a recommendation to do one over the other.
May 4 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
I'd think that if you had another namespace { } after the one you
defined, the former woudl keep the using confied to the first
namespace, while the latter would be global to the file.

Where did you see that the latter is prefered? None of the temples
when you create a new class have the using within the namespace; its
always been the outside.

Andy

May 4 '06 #2

P: n/a
V
I am guessing, but could it have anything to do with the scope of the
using statement. I use the latter one all the time myself.

I will be following this thread with interest to figure out the actual
reasons.

- Vaibhav
http://www.nagarro.com

May 4 '06 #3

P: n/a
Keith,

Consider this example:

// The following line imports namespace B types (Bar1 & Bar2).
using B;
namespace A.C.D
{
// The following line imports namespace A.B types (Foo1 & Foo2).
using B;
}

namespace A.B
{
public class Foo1 { }
public class Foo2 { }
}

namespace B
{
public class Bar1 { }
public class Bar2 { }
}
As you can see changing the location of the using statement changes
what it is imported. I believe the formal explanation is in section
10.7 of the C# specification (ECMA version).

"The scope of a namespace member declared by a
namespace-member-declaration
within a namespace-declaration whose fully qualified name is N, is the
namespace-body of every namespace-declaration whose fully qualified
name is N
or starts with N, followed by a period."

That is quite possibly the most confusing sentence I've ever read!

Brian

Keith Patrick wrote:
Can someone tell me the difference in terms of actual implications using:
namespace MyNamespace {
using System;

class MyClass {...}
}

vs.

using System;
namespace MyNamespace {

class MyClass {...}
}

are? There's a framework recommendation that the former be used (and some
ASP.Net templates create classes like this), but I use the latter. I've
tried both but could never determine a difference between the two, so I'm
unsure why there's a recommendation to do one over the other.


May 4 '06 #4

P: n/a
Have you tried it? For me intellisence shows Foo methods for both
declaration of B namespace, either outside or inside the A.C.D namespace,
which means that A.B is imported in both cases.
That's definitely not what I would expect.

Brian Gideon wrote:
Keith,

Consider this example:

// The following line imports namespace B types (Bar1 & Bar2).
using B;
namespace A.C.D
{
// The following line imports namespace A.B types (Foo1 & Foo2).
using B;
}

namespace A.B
{
public class Foo1 { }
public class Foo2 { }
}

namespace B
{
public class Bar1 { }
public class Bar2 { }
}

May 5 '06 #5

P: n/a
can you definetely say that it is not just a bug in intellisense?

--
"Sericinus hunter" <se*****@flash.net> schrieb im Newsbeitrag
news:eA***************@newssvr33.news.prodigy.com. ..
Have you tried it? For me intellisence shows Foo methods for both
declaration of B namespace, either outside or inside the A.C.D namespace,
which means that A.B is imported in both cases.
That's definitely not what I would expect.

Brian Gideon wrote:
Keith,

Consider this example:

// The following line imports namespace B types (Bar1 & Bar2).
using B;
namespace A.C.D
{
// The following line imports namespace A.B types (Foo1 & Foo2).
using B;
}

namespace A.B
{
public class Foo1 { }
public class Foo2 { }
}

namespace B
{
public class Bar1 { }
public class Bar2 { }
}

May 5 '06 #6

P: n/a
cody wrote:
can you definetely say that it is not just a bug in intellisense?


Well, it also compiles fine when I use Foo, in both cases.
May 5 '06 #7

P: n/a

Sericinus hunter wrote:
Have you tried it?
I tried it in both 1.1 and 2.0 with the same result.
For me intellisence shows Foo methods for both
declaration of B namespace, either outside or inside the A.C.D namespace,
which means that A.B is imported in both cases.
My intellisense worked correctly. Did you try compiling it?
That's definitely not what I would expect.


Yeah, it's not what I would expect either, but I think the C#
specification agrees with the behavior observed.

May 5 '06 #8

P: n/a

Sericinus hunter wrote:
cody wrote:
can you definetely say that it is not just a bug in intellisense?


Well, it also compiles fine when I use Foo, in both cases.


Can you post your code? When put "using B" outside of namespace A.C.D
I get a compile error when I try to use Foo inside of namespace A.C.D.

May 5 '06 #9

P: n/a
Brian Gideon wrote:
Sericinus hunter wrote:
cody wrote:
can you definetely say that it is not just a bug in intellisense?

Well, it also compiles fine when I use Foo, in both cases.


Can you post your code? When put "using B" outside of namespace A.C.D
I get a compile error when I try to use Foo inside of namespace A.C.D.


Here it is:

using B;
namespace A.C.D
{
//using B;
class acd
{
acd()
{
int i = B.ab.aba;
}
}
}

namespace B
{
class b
{
static public int ba;
}
}

namespace A.B
{
class ab
{
static public int aba;
}
}
May 5 '06 #10

P: n/a
Okay. I see why it compiles now. You're qualifying the class ab with
the partial namespace identifier B. The behavior is exactly the same
as placing "using B" inside the namespace A.C.D and referring to class
ab directly. That makes sense and is in agreement with the
specification.

Try changing:

int i = B.ab.aba;

to

int i = ab.aba;

Then play around with the placement of the using statement.

Sericinus hunter wrote:
Brian Gideon wrote:
Sericinus hunter wrote:
cody wrote:
can you definetely say that it is not just a bug in intellisense?
Well, it also compiles fine when I use Foo, in both cases.


Can you post your code? When put "using B" outside of namespace A.C.D
I get a compile error when I try to use Foo inside of namespace A.C.D.


Here it is:

using B;
namespace A.C.D
{
//using B;
class acd
{
acd()
{
int i = B.ab.aba;
}
}
}

namespace B
{
class b
{
static public int ba;
}
}

namespace A.B
{
class ab
{
static public int aba;
}
}


May 5 '06 #11

P: n/a
You are right.

Brian Gideon wrote:
Okay. I see why it compiles now. You're qualifying the class ab with
the partial namespace identifier B. The behavior is exactly the same
as placing "using B" inside the namespace A.C.D and referring to class
ab directly. That makes sense and is in agreement with the
specification.

Try changing:

int i = B.ab.aba;

to

int i = ab.aba;

Then play around with the placement of the using statement.

Sericinus hunter wrote:
Brian Gideon wrote:
Sericinus hunter wrote:
cody wrote:
> can you definetely say that it is not just a bug in intellisense?
Well, it also compiles fine when I use Foo, in both cases.
Can you post your code? When put "using B" outside of namespace A.C.D
I get a compile error when I try to use Foo inside of namespace A.C.D.

Here it is:

using B;
namespace A.C.D
{
//using B;
class acd
{
acd()
{
int i = B.ab.aba;
}
}
}

namespace B
{
class b
{
static public int ba;
}
}

namespace A.B
{
class ab
{
static public int aba;
}
}

May 5 '06 #12

P: n/a
asp.net web controls embed the using section in the namespace.
The place I saw it was in a Brad Abrams blog post regarding the .Net
conventions, and that was one. But unfortunately, the rationale wasn't
placed in the rule, so I couldn't figure out why it was recommended.
May 10 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.