I am just looking at a project and I'm seeing something working which I didn't think should work.
If you look at the snippet below I'm in the namespace CustomFields.DateTimeField.Drivers, and the only other using statements in that file are other namespaces below CustomFields.DateTimeField.
But if you look on the public class DateTimeFieldDriver line it is using a type Fields.DateTimeField.
Looking at the definition of DateTimeField thats in the namespace CustomFields.DateTimeField.Fields but I have only set usings for its sister namespaces.
So the question is twofold - why does this work? is this considered a bad practice?
Snippet in question:
using System;
using JetBrains.Annotations;
using Orchard;
using Orchard.ContentManagement;
using Orchard.ContentManagement.Drivers;
using Orchard.Localization;
using CustomFields.DateTimeField.Settings;
using CustomFields.DateTimeField.ViewModels;
namespace CustomFields.DateTimeField.Drivers {
[UsedImplicitly]
public class DateTimeFieldDriver : ContentFieldDriver<Fields.DateTimeField> {
public IOrchardServices Services { get; set; }
private const string TemplateName = "Fields/Custom.DateTime"; // EditorTemplates/Fields/Custom.DateTime.cshtml
public DateTimeFieldDriver(IOrchardServices services) {
Services = services;
T = NullLocalizer.Instance;
}
The project can be downloaded here if you want to investigate it (MVC2 project).
When you declare code to be inside a particular namespace, for example, CustomFields.DateTimeField.Drivers, you are implicitly importing all the "parent" namespaces as well.
In this case, you have an implied using for CustomFields and CustomFields.DateTimeField. This is why you do not have to specify an explicit using statement for types in CustomFields.DateTimeField and furthermore, for subnamespaces contained therein.
Thus Fields.DateTimeField is found by combining CustomFields.DateTimeField (the implied namespace) with Fields.DateTimeField (the explicit namespace) to resolve to CustomFields.DateTimeField.Fields.DateTimeField.
And no, as far as I know this is not considered bad practice.
In C#, when you're within a namespace, you have implicit using for each of the parent namespaces. For example in this file:
using System;
namespace Foo.Bar.Baz {
class Qux {
}
}
\EOF
Is the same as this file:
using System;
using Foo;
using Foo.Bar;
namespace Foo.Bar.Baz {
class Qux {
}
}
\EOF
If you have a namespace imported, then you don't need to specify the full namespace to access members of a sibling namespace tree provided it has the same prefix as an imported namespace:
using Foo;
using Foo.Bar;
namespace Foo.Bar.Baz {
class Qux {
}
}
namespace Foo.Bar.Norf {
class Guf : Bar.Baz.Qux { // namespace `Foo.` is implicitly assumed to prefix the namespace reference `Bar.Baz`
}
}
\EOF
You're experiencing these two effects combined: implicit namespace prefix usage to an implicitly imported namespace.
As for "bad practice" - experienced C# developers will be familiar with this nuance, but generally it isn't a problem unless you have ambiguous names.
As a tip, try to minimize the number of namespaces and their depths. For example, in your case I see you're storing DateTime-specific stuff in its own DateTimeField namespace. This has a bad "code smell" to me. I would just put everything in the CustomFields namespace, especially as you've given each typename the prefix DateTime anyway, so it's just double-typing.
FxCop will complain if you have fewer than 5 types in a namespace too, btw.
Update: I took a look at the C# specification ( http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf ), section 16, but I can't find any part of it which states that parent namespaces are implicitly imported, which is strange.
Related
I'm confused why the following C# code won't compile, and instead generates the following:
error CS0234: The type or namespace name 'Module' does not exist in the namespace 'SomeName.Module.SomeName' (are you missing an assembly reference?)
using System;
namespace SomeName.Module.AnotherName
{
public struct SomeStruct
{
}
}
namespace SomeName.Module.SomeName
{
public class SomeClass
{
struct SomeNestedType
{
void SomeMethod(in SomeName.Module.AnotherName.SomeStruct someStruct)
{
}
}
}
}
I'm not aware of any namespace rules that would prevent it from finding the fully-qualified SomeName.Module.AnotherName.SomeStruct type.
The problem is that SomeName is being resolved as the final part of the namespace SomeName.Module.SomeName, and Module is being resolved relative to that.
If you absolutely can't change your namespaces, you can use the global namespace alias to disambiguate:
void SomeMethod(in global::SomeName.Module.AnotherName.SomeStruct someStruct)
However, it would be better to just use different names. For example, if you have namespaces of SomeName1.Module.AnotherName and SomeName1.Module.SomeName2 you don't get this problem - and the code will be easier for humans to read as well as the compiler. (Obviously it wouldn't actually be that name, but I can only hope that you're not really using SomeName in the first place. Pick good but different names for the two parts of the namespace.)
I'm finding some frustration with the way C# handles namespaces when I want to reference a class whose class name happens to be identical to part of the current class's namespace. This will produce a compiler error, "'Class' is a namespace but is used like a type".
Consider the following code sample, which demonstrates the problem:
namespace A.B.C
{
public class Y
{
}
}
namespace X.Y.Z
{
public class Class1
{
public Y MyProp;
}
}
In this case, I want to use the class "Y" from the namespace "A.B.C". But because "Y" is also one of the parts of the namespace, C# treats "Y" as a namespace, not a type.
I can get around this by fully qualifying the class name, "A.B.C.Y", or using an alias, but my general preference would be for C# not to treat "Y" as a namespace in this context. Often I have code, such as test code, that contains similar namespaces as classes its testing, and this kind of class/namespace collision means having to be a lot more verbose in setting things up.
I'm not sure what the process is called, but it seems that in resolving classes and namespaces, C# will walk up the namespaces until it finds a part of the namespace that matches. In this case, it walks up and finds Y. Is there a way to tell C# not to walk up, not to allow this partial namespace matching?
If you write using A.B.C; (the namespace that Y is in) inside namespace X.Y.Z, the error goes away:
namespace X.Y.Z
{
using A.B.C;
public class Class1
{
public Y MyProp;
}
}
I was wondering Why I can access class when I defined it outside of namespace scope?
I am not very familiar with namespaces, I am just learning, but I thought that namespace should like wrap all my classes to one 'box' and they can access each other just inside that 'box' (scope).
Code example:
class Point
{
public int X;
}
namespace ConsoleApplication12
{
class Program
{
static void Main(string[] args)
{
Point p = new Point();
p.X = 50;
Console.WriteLine(p.X);
Console.ReadLine();
}
}
}
Thank you for answers.
Namespaces have nothing to do with access. It's important to differentiate between namespaces and assemblies - they're often closely related, in that types in a namespace Foo.Bar would be likely to be in assembly Foo.Bar.dll, but that's a convention - it's not something the compiler or language cares about.
A namespace is primarily "a space in which names have to be unique". In other words, while it's fine to have two types called Point in different namespaces, you can't have two types called Point in the same namespace. Indeed, the primary reason for namespaces existing (IMO) is so that we don't all have to use completely unique names across every piece of .NET code in the world.
You can use your Point class which is implicitly internal so long as it's declared within the same assembly. If it's in the global namespace (i.e. not declared in a namespace at all) then you don't need any using directives to refer to it - the purpose of a using directive is to allow you to refer to members of a different namespace just by their short name.
So if you have:
namespace Foo.Bar
{
public class Baz {}
}
then you could access that as either:
namespace Other
{
class Test
{
Foo.Bar.Baz baz = new Foo.Bar.Baz();
}
}
or
// Allow anything in namespace Foo.Bar to be accessed by its
// short name
using Foo.Bar;
namespace Other
{
class Test
{
Baz baz = new Baz();
}
}
If the type is defined in the "global" namespace, then you just don't need the using directive. From the C# 5 language specification section 3.8 (namespace and type names) where it's describing the type name lookup procedure:
If the previous steps were unsuccessful then, for each namespace N, starting with the namespace in which the namespace-or-type-name occurs, continuing with each enclosing namespace (if any), and ending with the global namespace, the following steps are evaluated until an entity is located
So in your case, looking for Point from your Main method, first ConsoleApplication12 would be checked for a Point type, then the global namespace.
To access class, outside namespace, your class should be public
public class Point
and in your namespace, where you want to see this class, you need to add namespace in top of usings
using mynamespace.external;
Than you can access your class
I am writing code for a game, and wanted to include my main method in two different namespaces so that it could easily access all the classes from both the 'Engine' and 'Core' Namespaces.
namespace Engine Core
{
class ExampleClass
{
}
}
Although I just put a space between Engine and Core, I know that this syntax is incorrect, I would like to know how to make a class a member of multiple namespaces. If this is not possible, is there anything that I could do that would act the same? (Classes in neither these two namespaces having to refer to this class by 'Engine.' or 'Core.'
A class can not belong to two different namespaces.
If you want to refer to a class of the Engine or Core namespaces without explicitly writing the namespace each time you reference a type of those namespaces, just use using at the beginning of the file. The using directive allows the use of types in a namespace so that you do not have to qualify the use of a type in that namespace:
using Engine;
or
using Core;
Check the documentation: using Directive
So you want someone to be able to access ExampleClass by using Engine.ExampleClass and Core.ExampleClass? I'm not sure why you would (I'm sure you have your reasons) but two ways to expose something like this are:
namespace Foo
{
abstract class ExampleClass
{
//Only implement the class here
}
}
namespace Engine
{
class ExampleClass : Foo.ExampleClass
{
//Don't implement anything here (other than constructors to call base constructors)
}
}
namespace Core
{
class ExampleClass : Foo.ExampleClass
{
//Don't implement anything here (other than constructors to call base constructors)
}
}
Or you could use namespace aliasing but every cs file using the class would require the alias to be defined.
using Engine = Core;
Okay, there's System and System.Web. Am I correct in that the structure this suggests is:
namespace System
{
// all of the outer namespace members
namespace Web
{
// all of the inner members
}
}
And that when a namespace is nested within another, having a using directive with the parent/outer namespace only doesn't automatically bring in the child/nested namespace? In other words:
using System;
public class Example
{
public Example()
{
context1 = new HttpContext(); // won't work
context2 = new System.Web.HttpContext(); // will work
}
}
Just trying to see if I actually understand this correctly.
System.Web is declared as:
namespace System.Web
{
public class HttpContext {}
}
However, it would be possible to actually declare a child namespace:
namespace System
{
namespace Web
{
public class HttpContext {}
}
}
I have never seen something like this but the syntax allows it and the effect is the same. In both cases, the namespace of HttpContext is System.Web.HttpContext.
Even with the second example, using System; wouldn't import the child namespace, only the types defined in that namespace are imported.
You could nest namespaces and any using directive would only grant access to the members defined within the specific namespace you are referencing.
So from your example:
namespace System
{
// all of the outer namespace members
namespace Web
{
// all of the inner members
}
}
Referencing System would grant you access to the outer namespace members and referencing System.Web would grant you access to all of the inner namespace members.
But this is atypical and usually namespaces are defined only once within a file. The dot-notation typically follows a folder or project structure, so files that were nested as such:
WebApplication
- Models
- MyModel.cs
- Controllers
- MyController.cs
Might use namespaces of WebApplication.Models and WebApplication.Controllers.
I can't think of a great example off the top of my head where you would want to nest namespaces, but there may be a good reason to. However, it would be considered an exception to the rule, in my opinion.
Yes, a using directive only allows types declared in that namespace to be used without namespace qualifier. Nested namespaces are not automatically included.
As Daniel said, System.Web is not declared separately. System and System.Web are two separate namespaces which are technically unrelated.
That's why your code example of new HttpContext() won't work - because HttpContext is not in the System namespace at all.
this is a common confusion regarding composite namespaces. Heres a great article of microsoft about it: http://msdn.microsoft.com/en-us/library/ms973231.aspx