Neither of these are ambiguous. The language spec is very clear about
things that make this unambiguous. When doing name resolution namespaces
are searched before using clauses (and outer namespaces with outer using
clauses). Thus in this example namespace NA is searched for a name
"Configuration" before even looking at your outermost using clauses.
Secondly name resolution occurs without consideration for the context of
where the name is used. In your example it is obvious that you expect
Configuration to be a type-name, but name lookup does not include that
information, it simply looks for the first "Configuration", it is then an
error if the name that it finds is not used properly. The exact same
reasons apply to your original example.
--
--Grant
This posting is provided "AS IS" with no warranties, and confers no rights.
"Matt Mastracci" <ma**@aclaro.com> wrote in message
news:3F**************@aclaro.com...
Here's an example of more buggy (IMHO, of course) behaviour. Note that
in this case, a namespace higher the "current" namespace is interfering
with a reference from yet another namespace.
test1.cs
===========
using System;
using A.B;
namespace NA.NB.NC.ND
{
public class XXX
{
XXX() { Configuration c = new Configuration(); }
}
}
namespace NA.Configuration
{
}
test2.cs
===========
using System;
namespace A.B
{
public class Configuration
{
public Configuration() { X = 3;}
public int X;
}
}
Christian wrote:
Of course.
Doesn'it?
"Matt Mastracci" <ma**@aclaro.com> ha scritto nel messaggio
news:3F**************@aclaro.com...
Should the C# compiler then be marking the class with the same name as
the namespace as an error?
Nicholas Paldino [.NET/C# MVP] wrote:
Matt,
It is not unambiguous, and it is actually disallowed. You can not
have
a class in a namespace with the same name as the namespace explicitly
because of this. What if you had a nested type in class C? The
compiler
would have to guess without knowing what C is, and I wouldn't put my
trust
in any compiler that did that.
Hope this helps.