Type Inference != VB6 Variants
There seems to be a bit of confusion going on among people raised on Visual Basic 6 about one of the new features in .Net Framework 3.0--type inference. On several occasions, I have heard that type inference is basically the equivalent of an old feature of Visual Basic 6 where you could leave off the type declaration of a variable. It's important to realize that type inference is a different (and more programmer-friendly) animal altogether: with type inference, we have a stongly typed variable with compiler inferring the strong type of the variable at compile time. With Visual Basic 6, we had types of variants inferred at run-time, when an application was deployed, and it was the cause of many headaches and hours of technical support efforts. Let's take a look at a simple example to illustrate the key difference.
Suppose, we have the following VB6 code:
Dim strTest
strTest = "2a"
MsgBox (CInt(strTest) + 2)
This code will compile OK, but immediately after executing it, VB6 runtime will raise a "Type mismatch" error. Contrast this with the following
C# code:
var strTest = "2a";
System.Windows.Forms.MessageBox.Show((int)(strTest) + 2);
When you go to compile that code, you will get a compilation error stating that the C# compiler cannot convert type 'string' to 'int.' That's not your grandma's VB6 variant handling (although I do miss VB6 for many other reasons, since it was so fun to program in)!
Many people dismiss type inference as useless and potentially dangerous feature, but I believe it has a definite place in each .Net 3.0 programmer's toolbox. It may not be appropriate to use type inference for declaring variables of simple types (integer, string, etc.), but it's a real time-saver for more complex types, especially types derived from LINQ queries. Consider the following LINQ statement (borrowed from 101 LINQ samples):
var upperLowerWords =
from w in words
select new {Upper = w.ToUpper(), Lower = w.ToLower()};
Here, the type upperLowerWords is automatically inferred as a collection of objects, each object containing two properties: Upper and Lower. What would be the alternative to automatic type inference to arrive at the same result? Let's see, first we would have to declare the data class:
public class upperLowerWord
{
private string _Upper;
private string _Lower;
public string Upper
{
get { return _Upper;}
set { _Upper = value; }
}
public string Lower
{
get { return _Lower; }
set { _Lower = value; }
}
}
Second, we would have to declare a generic list of upperLowerWord classes and use LINQ query to retrieve the actual data:
IEnumerable<upperLowerWord> upperLowerWords = from w in words
select new upperLowerWord { Upper = w.ToUpper(), Lower = w.ToLower() };
I think it's clear that type inference (also referred to as "anonymous types" feature for the LINQ example above, since the new type is being created "on the fly") saves on manual typing. But even greater benefit of type inference, in my opinion, is that it allows you to concentrate on the logical flow of your application more so than on ensuring that all the types used are being correctly declared and no getter/setters are missed.
Windows Presentation Foundation Unleashed by Adam Nathan, et al.
The work load and a couple of fun side projects have finally caught up with me, and I did not get a chance to finish reading the "WPF Unleashed" book by Adam Nathan. But, I feel that I have read enough of it to state my opinion about the book.
The most important thing about “WPF Unleashed” is that it inspires. It inspires its readers to start developing application using the next generation of UI technologies--WPF. Full-color illustrations of what the future UIs will look like drive the point home. A detailed and in-depth breakdown of how to program these interfaces of the future only makes the book so much more valuable. The target audience is developers wishing to learn the intricacies of WPF programming, including constructing XAML and the C# code-behind involved. From the beginning, the author makes it clear that you may never have to write a single line of XAML by hand, since tools such as Microsoft Expression Blend could do that for you. But, his analogy of knowing HTML vs. coding in Dreamweaver or FrontPage is a valid one--sometimes there are and will be items not easily customizable via visual tools.
Allow me to briefly talk about book's contents. The first part of the book starts out with how we got to WPF: the history of graphical interfaces, intro to XAML, as well as some important new concepts in WPF, including the logical and visual trees, dependency properties, and routed events. The second part deals with building WPF applications: the overview of controls, sizing and positioning of the elements, as well as structuring and deploying an application. The third part talks about using Resources, Data Bindings, and themes. The fourth part is the coolest: 2D and 3D graphics, animations, as well as dealing with various types of media (music and video) are described, and Adam even briefly touches on speech recognition. The final part of the book deals with advanced subjects of creating user and custom controls, interoperability with legacy technologies (Win32 forms, ActiveX controls) and layout with custom panels.
One of the surprising things learned from the book was that new Vista features, including the Aero glass (transparent window border extended into the client area), are exposed via unmanaged APIs, so to consume these features in C# or VB.Net application (managed code), we must use the PInvoke method (that is, a DLLImport attribute).
For the final words: if you want to get inspired about WPF development, get this book, browse through it, and see what's possible in WPF. Then, keep it as a reference as you develop your applications. I am almost certain you will want your next project to be WPF-based after getting familiar with this work. 4 stars out of 4.