Mastering C# and Unity3D

From AS3 to C#, Part 13: Where Everything Goes

Today we continue the series by wrapping up C#’s class/interface/struct/enum system with a discussion of where to put them all. We’ll focus on package/namespace, organizing types into files, and some details of using/import.

C# does this a little differently. The namespace keyword replaces package. Instead of using package with no name, you can just omit the namespace altogether.

// MyClass.cs - not in a namespaceclass MyClass {}// MyInterface.cs - not in a namespaceinterface MyInterface {}// MyEnum.cs - not in a namespaceenum MyEnum {}// MyStruct.cs - not in a namespacestruct MyStruct {}// com/jacksondunstan/examples/MyClass.cs - in a namespacenamespace com.jacksondunstan.examples{class MyClass {}}// com/jacksondunstan/examples/MyInterface.cs - in a namespacenamespace com.jacksondunstan.examples{interface MyInterface {}}// com/jacksondunstan/examples/MyEnum.cs - in a namespacenamespace com.jacksondunstan.examples{enum MyEnum {}}// com/jacksondunstan/examples/MyStruct.cs - in a namespacenamespace com.jacksondunstan.examples{struct MyStruct {}}

The paths for each of these files are just suggestions with C#. You can put them anywhere, but the convention is for the paths to match the namespace names like in AS3. For usage, the using keyword replaces import and you omit the .* portion when importing a whole package/namespace:

usingcom.jacksondunstan.examples;namespace myexamples
{publicclass Example
{// Now use something from the namespaceprivate MyClass myc;}}

If you have a static class, you can import just that from a namespace by adding its name to the using statement:

usingcom.jacksondunstan.examples.MyStaticClass;

You can also move the using statements inside your namespace for a subtle difference in behavior:

namespace myexamples
{usingcom.jacksondunstan.examples;publicclass Example
{// Now use something from the namespaceprivate MyClass myc;}}

If the using is outside the namespace myexamples then the myexamples namespace will be searched for MyClass before com.jacksondunstan.examples is. It’s the other way around if you put the using statement inside the namespace examples.

Another feature of using is to create aliases. This is useful when you’ve got identically-named classes in multiple namespaces and would rather not use fully-qualified names.

Finally, let’s summarize this all with a quick comparison between C# and AS3 for everything discussed today:

////////// C# //////////// Type outside of a packagepublicclass MyClass {}// Type inside a packagenamespace mypackage
{publicclass MyClass
{// Nest a typepublicclass NestedClass {}}}// Another type in the same filepublicclass HelperClass {}// Get access to the types in a packageusingmypackage;// Get access to a type in a package - static classes only in C#usingmypackage.MyStaticClass;// Create an alias for a type in a packageusingUnityObject = UnityEngine.Object;// Explicitly use a type in a package
mypackage.MyClass myc;// Explicitly use a type outside of a package
global::MyClass myc;

/////////// AS3 ///////////// Type outside of a packagepackage{publicclass MyClass {}}// Type inside a packagepackage mypackage
{publicclass MyClass
{// Nest a type// {impossible in AS3}}}// Another type in the same file: non-public onlyinternalclass HelperClass {}// Get access to the types in a packageimport mypackage.*;// Get access to a type in a packageimport mypackage.MyClass;// Create an alias for a type in a package// {impossible in AS3}// Explicitly use a type in a packagevar myc:mypackage.MyClass;// Explicitly use a type outside of a packageglobal::MyClass myc;

This wraps up C#’s object model. Next week we’ll move on to the remainder of the syntax (types, casts, etc.). Stay tuned!

Comments

Namespaces and packages are not exactly equivalent. Packages in AS3 imply the directory structure of the source whereas namespaces primarily have to do with the organization of the code. AS3 uses the directory structure to support its “object-orientedness” and build in some additional modularity, C# doesn’t particularly care about the directory or even if there is one (you technically can write any C# program in one file, just like C). That said, I don’t suppose there’s anything stopping someone from using C# namespaces like packages, but it will look very strange to all the other C# programmers – and someone will probably tell you you’re doing it wrong.

That’s a good point- namespaces need not match the directory structure like packages require in AS3. However, from my experience it’s common for them to match somewhat closely. For example, Microsoft Visual Studio (at least version 2013) will auto-name your namespaces based on the directory the file is in. In the end though, it’s what you say- up to the individual programmer or team of programmers to come up with whatever naming convention they want. C# allows that flexibility.