[Help] Confusion about a NameSpace Name resolution issue...

  • Thread starter Thread starter Shawn Anderson
  • Start date Start date
S

Shawn Anderson

I ran into something that I consider a little strange this weekend and I was
wondering if any of the Gurus out there could explain it to me. Here is a
sample piece of code that will not compile because of line 11.

1: using System;
2:
3: namespace eyecatcher.System
4: {
5: class CommandLineParser
6: {
7: private string m_sCmdLine;
8:
9: public CommandLineParser()
10: {
11: Parse(System.Environment.CommandLine); <-- Error occurs
here.
12: }
13:
14: public CommandLineParser(string sCmd)
15: {
16: Parse(sCmd);
17: }
18:
19: private void Parse(string sCmd)
20: {
21: m_sCmdLine = sCmd;
22: }
23: }
24: }

However if I change line 11 to look like this:

Parse(Environment.CommandLine);

Everything works.

I spent a large portion of this weekend looking through the language specs
and I could find no reason as to why my code failed. As a matter of fact,
it seemed more likely (according to the documentation) that my fix should
actually be causing an error and my original code should be correct.

Anyways, if anyone has any helpful insights I would greatly appreciate it.

Thanks
Shawn Anderson
 
Shawn said:
I ran into something that I consider a little strange this weekend and I was
wondering if any of the Gurus out there could explain it to me. Here is a
sample piece of code that will not compile because of line 11.

1: using System;
2:
3: namespace eyecatcher.System
4: {
5: class CommandLineParser
6: {
7: private string m_sCmdLine;
8:
9: public CommandLineParser()
10: {
11: Parse(System.Environment.CommandLine); <-- Error occurs
here.
12: }
13:
14: public CommandLineParser(string sCmd)
15: {
16: Parse(sCmd);
17: }
18:
19: private void Parse(string sCmd)
20: {
21: m_sCmdLine = sCmd;
22: }
23: }
24: }

However if I change line 11 to look like this:

Parse(Environment.CommandLine);

Everything works.

I spent a large portion of this weekend looking through the language specs
and I could find no reason as to why my code failed. As a matter of fact,
it seemed more likely (according to the documentation) that my fix should
actually be causing an error and my original code should be correct.

Anyways, if anyone has any helpful insights I would greatly appreciate it.

Thanks
Shawn Anderson
Click to expand...

The relevant section of the C# spec is Section 3.8 (Namespace and type
names). It's not an easy read.

In your initial code, the System.Environment.CommandLine
namespace-or-type-name is being resolved in the eyecatcher.System
namespace.

The compiler tries first to resolve the System identifier (from
System.Environment.CommandLine) in namespace eyecatcher.System, but does
not find a matching namespace or type there.

Then the compiler tries to match the System identifier in the eyecatcher
namespace, and it finds the System namespace inside of the eyecatcher
namespace. It does this because (quoting from section 3.8): "starting
with the namespace in which the namespace-or-type-name occurs (if any),
continuing with each enclosing namespace (if any), and ending with the
global namespace, ..."

So now it has a match, and it tries to resolve the Environment
identifier in the eyecatcher.System namespace, which fails.

When you changed the name to "Environment.CommandLine", the Environnment
identifier is not found in the enclosing eyecatcher.System or
eyecatcher namespaces, so it looks in the imported namespaces (from the
using declarations), where it finds a match in the System namespace.
 
Hmm, ok that makes sense. It is too bad the spec doesn't allow for
something like the "::" in C++ to denote an absolute global namespace -->
::System.Environment.CommandLine. That way we could help the compiler
understand that the namespace we are talking about starts with "System".

Thanks again,
Shawn
 
mikeb said:
So now it has a match, and it tries to resolve the Environment
identifier in the eyecatcher.System namespace, which fails.
Click to expand...

Since that failed, then why couldn't it keep going to the next enclosing
namespace-or-type-name (System, which would also fail), then finally on to
the global namespace (which would then succeed)?

-- Alan
 
Alan said:
Since that failed, then why couldn't it keep going to the next enclosing
namespace-or-type-name (System, which would also fail), then finally on to
the global namespace (which would then succeed)?

-- Alan
Click to expand...

Don't know - I'm just describing what the spec currently says. However,
I do like Shawn's idea of a global namespace 'operator', and if anyone
from MS is listening, I'd think it could be added without any danger of
breaking existing code. I imagine it's too late for Whidbey.
 
Back
Top