/pcq/media/agency_attachments/L8pkS8gpnodJThOdAfv1.jpg)
Follow UsWith the .NET Framework’s last release, v1.1, Microsoft introduced a good amount of newer functionality, such as built in support for ODBC/Oracle based data access, enhancements to various namespaces and classes and more. But, v1.1 is a minor release when compared with the technologies and features being introduced in the upcoming version of the .NET Framework, codenamed Whidbey. This version carries a lot of punch that will surely impress the developer in you. We help you understand what Whidbey is, what new features and technologies it packs, and how you can take advantage of them. Whidbey beta isn’t publicly available yet. We will lead you through the realms of the technology, being your guide in the quest for understanding it, to get you started the moment it’s released.
Generics: Template-based development for .NET
If you have been a C++ developer who shifted to .NET, you may have missed template-based development. For those who are not clear about templates, or don’t know what they are, the following example will help clear this concept.
Assume that you have to write code to maintain a stack of numbers. Now, numbers could be integers, floats, longs, etc. Thus, depending upon the data type you choose to implement the stack, the memory requirements for the stack data-structure implementation will vary. But, what if you are required to have stack implementations for all the three types we talked about earlier? One would write three separate stack implementations for each of the types. This involves a lot of development time, not to mention code duplicity.
However, if one would use the concept of template-based development, the developer would write a common code, independent of type-specification at class/method implementation that would cater to all the types. The type will be specified during the instantiation of the class, or the invocation of the method. And such class or methods are termed as template class or template methods in C++. In Whidbey¸ Microsoft is adding support to write such generic classes and methods, the feature being called Generics, using the various .NET grammars. By the time it is released, the next versions of C# and VB.NET will be supporting Generics. So what does this imply for you, the developer? Well, here it goes:
MSIL will have new opcodes to support generics
You will be able to use the C++ template concepts to write code that will work against various data types.You won’t need to fall back on System.Object to implement such a generic system. The FCL (Framework Class Library) will have support for various general-purpose classes, like List, with their Generic versions. Finally, you could write code like below that specifies what data-type the Stack (just an example) implementation will use, during object instantiation.
Stack
Does that mean Generics will work just as C++ templates? Do they give any performance benefits? We will answer these and more of such questions in subsequent articles when we talk about Generics in particular.
Partial Types: Splitting CLR type implementation across files
Did your CLR type (read class for simplicity) implementation ever became too big? Did you wish you could segregate the implementation of class methods and properties in a logical manner (maybe functionally) and split the implementation across different source files? Partial Types allows you to do that. A new keyword, partial, allows classes and structs to be implemented across multiple source files. So, while one developer can work on business logic, another can work on the scalability and this can be done in two different files. For example:
A.CS
partial public class MyClass
{
public void MethodA(){ // implementation comes here }
}
B.CS
partial public class MyClass
{
public void MethodB(){ // implementation comes here }
}
Both the implementations will reside under the same namespace. When both these files are compiled, the compiler will know that both refer to the same class (since they have the same class name and optionally, the same namespace), and thus, at compile time, it will spit out IL which will be equivalent to having the following class implementation.
public class MyClass
{
public void MethodA(){ // implementation comes here }
public void MethodB(){ // implementation comes here }
}
Thus, you end up implementing a rather complex type, with teams working independent of one another, using separate source files, rather than trying to synchronize the source or waiting on checkouts.
Anonymous Methods: Lambda function
There is a programming concept that goes by the name Lambda Function that carries the notion of allowing developers to create code blocks that can be invoked later, but differing from a typical function implementation in that when the developer codes them, there is no function body written explicitly for them. In Whidbey, this concept is implemented as Anonymous Methods. Typically, Anonymous Methods would be used for replacing a delegate. As of today, a delegate implementation is something like this.
btnAdd.Click+=new EventHandler(btnAdd_Click);
void btnAdd_Click(object sender, EventArgs, e)
{
// implementation comes here
}
As evident, btnAdd_Click is the delegate that will be called back when the button-click occurs. The current implementation expects us to specify the delegate to be called when an event occurs and implement it as a method separately. Anonymous Methods change this programming paradigm. The very reason they are anonymous is because they have no (method) name. Have a look at how the above snippet would be implemented using Anonymous Methods.
btnAdd.Click+=delegate (object sender, EventArgs, e)
{
// implementation comes here
}
It becomes anonymous since the external method implementation goes out and the associated code block is directly associated. And unlike a separate method implementation that cannot access the local variables in the scope of function setting up the delegate, code blocks of Anonymous Methods can actually access the local variables. And the best thing is that the system attempts to identify the delegate type, wherever it is possible.
Iterators: Better enumeration
If you have built your own enumerators to loop through values contained in your custom CLR type, you will know how cumbersome it is. For each type that requires the enumeration functionality, you would be required to implement a different one. Infact, the C# foreach loop also uses the enumerator internally. The snippet below
foreach(object obj in mylist){
DoSomeWork(obj);
}
actually expands to:
Enumerator en = mylist.GetEnumerator();
while(en.MoveNext()){
object obj = en.Current;
DoSomeWork(obj);
}
In Whidbey, Iterators relieve us from implementing enumeration support. A new keyword, yield will make the compiler spit out IL for implementing an enumerator support for the type, without requiring the developer to do. For example:
public class myList
{
internal object<> elements;
internal int count;
public myListEnumerator GetEnumerator(){
return new myListEnumerator(this);
}
}
In this custom type myList, to enumerator through the list of elements, we implement myListEnumerator that shall implement IEnumerator and does all the hardwork. And this has to be implemented by the developer manually. Using Iterators, the above snippet gets changed to the following:
public class myList
{
internal object<> elements;
internal int count;
public IEnumerator GetEnumerator(){
for(int i=0;i
yield return elements;
}
}
}
The yield keyword returns an IEnumerator and thus, when foreach is applied as myList, enumeration happens. And the best part is, you don’t implement any class/functionality that returns IEnumerator! That compiler does for you, by creating a class thatdoes all the relevant work!
MARS: Single connection, multiple resultsets
Whidbey, in its implementation of ADO.NET, supports MARS¸ or Multiple Active Resultsets, which the upcoming version of SQL Server (codenamed Yukon) also supports. Prior to MARS, developers had to either cancel or process all resultsets from one batch, executing on a given connection, before another batch could be executed against the same connection. With MARS, this isn’t required. Of course, these will be supported by Yukon only and .NET 1.1 or earlier applications will not be able to have MARS support using server-side cursors. There will be more to follow on MARS as the series progresses.
Kumar Gaurav Khanna, runs wintoolzon