13.07.2015 Views

C# in Depth

C# in Depth

C# in Depth

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

194 CHAPTER 7 Conclud<strong>in</strong>g <strong>C#</strong> 2: the f<strong>in</strong>al featuresnamespace or type (for example, us<strong>in</strong>g Out = System.Console;) and the other just<strong>in</strong>troduced a namespace <strong>in</strong>to the list of contexts the compiler would search whenlook<strong>in</strong>g for a type (for example, us<strong>in</strong>g System.IO;). By and large, this was adequate,but there are a few situations that the language simply couldn’t cope with, and otherswhere automatically generated code would have to go out of its way to make absolutelysure that the right namespaces and types were be<strong>in</strong>g used whatever happened.<strong>C#</strong> 2 fixes these problems, br<strong>in</strong>g<strong>in</strong>g an additional robustness to the language. It’snot that the code be<strong>in</strong>g generated is any more robust <strong>in</strong> terms of execution, but youcan write code that is guaranteed to mean what you want it to regardless of whichother types, assemblies, and namespaces are <strong>in</strong>troduced. These extreme measures arerarely needed outside automatically generated code, but it’s nice to know that they’rethere when you need them. In <strong>C#</strong> 2 there are three types of aliases: the namespacealiases of <strong>C#</strong> 1, the global namespace alias, and extern aliases. We’ll start off with the onetype of alias that was already present <strong>in</strong> <strong>C#</strong> 1, but we’ll <strong>in</strong>troduce a new way of us<strong>in</strong>galiases to ensure that the compiler knows to treat it as an alias rather than check<strong>in</strong>g tosee whether it’s the name of another namespace or type.7.4.1 Qualify<strong>in</strong>g namespace aliasesEven <strong>in</strong> <strong>C#</strong> 1, it was a good idea to avoid namespace aliases wherever possible. Every sooften you might f<strong>in</strong>d that one type name clashed with another—as with our Buttonexample earlier—and so you either had to specify the full name <strong>in</strong>clud<strong>in</strong>g thenamespace every time you used them, or have an alias that dist<strong>in</strong>guished the two, <strong>in</strong>some ways act<strong>in</strong>g like a shortened form of the namespace. List<strong>in</strong>g 7.5 shows an examplewhere the two types of Button are used, qualified by an alias.List<strong>in</strong>g 7.5Us<strong>in</strong>g aliases to dist<strong>in</strong>guish between different Button typesus<strong>in</strong>g System;us<strong>in</strong>g W<strong>in</strong>Forms = System.W<strong>in</strong>dows.Forms;us<strong>in</strong>g WebForms = System.Web.UI.WebControls;class Test{static void Ma<strong>in</strong>(){Console.WriteL<strong>in</strong>e (typeof (W<strong>in</strong>Forms.Button));Console.WriteL<strong>in</strong>e (typeof (WebForms.Button));}}List<strong>in</strong>g 7.5 compiles without any errors or warn<strong>in</strong>gs, although it’s still not as pleasantas it would be if we only needed to deal with one k<strong>in</strong>d of Button to start with. There’sa problem, however—what if someone were to <strong>in</strong>troduce a type or namespace calledW<strong>in</strong>Forms or WebForms? The compiler wouldn’t know what W<strong>in</strong>Forms.Button meant,and would use the type or namespace <strong>in</strong> preference to the alias. We want to be able totell the compiler that we need it to treat W<strong>in</strong>Forms as an alias, even though it’s availableelsewhere. <strong>C#</strong> 2 <strong>in</strong>troduces the ::syntax to do this, as shown <strong>in</strong> list<strong>in</strong>g 7.6.Licensed to Rhona Hadida

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!