Namespaces
As you experienced in the previous
exercise, Windows Runtime types have hierarchical names. For example,
the enumeration with the resolution scale values has the full name of Windows.Graphics.Display.ResolutionScale. The last tag of this name is the type’s simple name, and prefix tags form the namespace hierarchy. The top-level namespace is Windows. It has an embedded namespace, Graphics, and Graphics embeds Display.
NOTE .NET, Java, and C++
programmers are familiar with the concept of namespaces. Windows
Runtime uses the namespace with exactly the same semantics as applied
in .NET.
Namespaces are important concepts when managing
the vast amount of types you utilize while creating your applications.
If you had only type names poured into a big pool, it would be very
difficult to find them and guess what type is the appropriate one for a
certain task.
Another issue would be naming types. You cannot
guarantee that no one else uses the same type name that you use. For
example, when you name your type Circle,
there is a great likelihood that someone else will use the same name.
If you buy a package of custom UI components, there already may be a Circle type. How will your application know which Circle type to use at a certain location of the source code, and whether you intend to use your own Circle or the purchased one?
Namespaces are great constructs that help you to
group objects into categories. Using well-designed namespace
hierarchies makes you more productive, because you can find appropriate
types for a certain task easily. For example, when you are about to
display images on the screen, first you will look them in the Windows.Graphics.Imaging namespace, because its name suggest that such types exist there.
Namespaces also help you avoid conflicting type
names. If you put your own types into their own namespaces (for
example, you put Circle into the MyCompany.Shapes namespace), they won’t clash with types from other programmers or companies.
Types can have pretty long full names.
Fortunately, all programming languages that manage the concept of
namespaces offer some kind of constructs to avoid full names, and allow
writing only the simple names. Let’s take a look at a few examples.
C# offers the using clause to help resolve type names:
using Windows.UI.Xaml;
namespace MyAppNamespace
{
class MyClass: UserControl
{
public MyClass()
{
// ...
selectedItem = this.FindName(itemName) as ListBoxItem;
// ...
}
}
}
Visual Basic offers the same construct with the Imports keyword:
Imports Windows.UI.Xaml
Namespace MyAppNamespace
Class MyClass
Inherits UserControl
Public Sub New()
' ...
selectedItem = TryCast(Me.FindName(itemName), ListBoxItem)
' ...
End Sub
End Class
End Namespace
It is not surprising that C++ offers the same concept with the using namespace clause, too:
using namespace Windows::UI::Xaml;
namespace MyAppNamespace
{
class MyClass: UserControl
{
public MyClass()
{
// ...
selectedItem = dynamic_cast<ListBoxItem^>(this->FindName(itemName);
// ...
}
}
}
The using, Imports, and using namespace
constructs in C#, Visual Basic, and C++, respectively, instruct the
compiler that type names should be looked up in the specified
namespaces. This mechanism allows writing only ListBoxItem type names in your programs, because the compiler will check the Windows.UI.Xaml namespace as well. Otherwise, you would have to write the full Windows.UI.Xaml.ListBoxItem name.
NOTE Of course,
objects in Windows Runtime namespaces can be accessed from JavaScript
programs, too.
