Visual
C# version 4.0 offers new features that make it easier for you to work
in dynamic programming scenarios. Besides dynamic programming, you have
support for optional and named parameters, better COM interop support,
and contra-variance and covariance. This article will show you how each
of these features work and provide suggestions of
how they can be applied to help you be more productive.
To
help you follow the path of C#, this article looks at the history of
C#, today’s use of C#, and helps you understand the future of C# and
what the language intends to provide for you. After you understand the
theme of C# 4.0, you’ll learn about the new features of C# 4.0. Finally,
this article will show you how to create a dynamic object of your own
with late-bound calls to dynamic methods based on conventions.
C#: Then and Now
The
previous major versions of C# were 1.0, 2.0, and 3.0. There was a minor
version 1.1 in April of 2003, but it didn’t significantly change the
theme of the 1.0 release. I’ll discuss these versions in the following
sections.
Microsoft
first announced C# on June 16th 2000. It was the first high-level
programming language that was built specifically to target the .NET
Common Language Runtime. C# 1.0 grew its heritage from C++, but borrowed
features from languages such as Delphi, Java, and others. In C# 1.0,
Microsoft planned to provide an object-oriented, component-based
language that was very simple to use. When Microsoft released C# 1.0 to
manufacturing on February 13th 2002, it was an immediate hit and
steadily grew in popularity.
When
C# 2.0 rolled around, Microsoft finally added all of the features that
should have been in C# 1.0. For example, generics was huge and is an
important part of .NET development today. C# 2.0 also introduced
anonymous methods, iterators, and nullable types. An interesting
addition to C# 2.0, nullable types was a pre-cursor feature for what was
coming in the next version, focusing on data.
Most
developers work with data, which was the primary theme of C# 3.0. The
largest C# 3.0 language addition was Language Integrated Query (LINQ).
Most other language features added in C# 3.0 were primarily to support
LINQ, but the new features; including implicitly typed local variables,
anonymous types, object and collection initializers, lambdas, and
extension methods, can have value on their own in development that
doesn’t involve LINQ.
The
next version of C# will be 4.0, which is the focus of this article. C#
4.0 will primarily focus on dynamic programming. The following sections
of this article explain the dynamic programming features of C# 4.0 as
well as other new features such as optional/named parameters and
covariance/contravariance.
Why Dynamic Programming?
The
dynamic programming story in C# can fall into fulfilling categories of
need in the way of multiple-language integration, simpler reflection,
access to HTML DOM in Web scenarios, and easier COM interop. Some of
these categories of need might not apply to your particular situation,
and that’s okay because there isn’t anything that says that you have to
use a language feature just because it’s there. Therefore, I’ll give you
an idea of how someone with a specific need might find value in C# 4.0
dynamic programming.
| " |
C# 4.0 will primarily focus on dynamic programming.
| " |
Most
C# developers use multiple tools in a single application to accomplish
complex tasks. If you’re writing WPF desktop applications, you’re using
C# and XAML. It is quite possible that you might find some open source
code that solves a problem, but it might be written in another language
such as VB or F#. One of the benefits of .NET since its inception is the
ability to have cross-language interoperability and the runtime is even
called the “Common Language” Runtime (CLR). In recent years, Microsoft
has created dynamic languages, such as IronRuby and IronPython, but
developers don’t have an easy way to perform interop with dynamic
languages. If you have this need, then you’ll welcome the ease with
which C# dynamic programming makes interop between C# and dynamic
languages possible.
When
performing reflection to run a method on an object, there are several
hoops to jump through, including obtaining a reference to an object
type, getting a reference to a member info object, determining the type
of bindings to use, and then invoking the member. While reflection has
an undeniable coolness factor, it still feels like a hack and that’s
where C# 4.0 dynamic methods can help. Later in this article, I’ll show
you how to just call the object member.
If
you write Silverlight applications, you might have the need today or in
the future to access the HTML DOM containing your Silverlight control.
C# dynamic programming makes this task easier.
Performing
COM interop with C# has always been cumbersome; partly because of the
need to write extra syntax for conversions, optional parameters, and
more. This has left some C# developers with a touch of VB envy because
VB has easier COM interop support. One of the purposes of dynamic
programming in C# is to help the C# programmer write cleaner syntax in
COM interop scenarios.
I’ve
spent some time explaining some of the potential benefits of dynamic
programming because it’s so new that the value might not jump out at you
immediately. In following sections, I’ll share the how so that you can match it up with the why that
you might care about. Before diving into dynamic programming, let’s
look at a couple other new features of C# 4.0, optional and named
parameters.
Optional Parameters
| " |
If you’re of the same mind, then you’ll probably be pleased that C# 4.0 supports optional parameters.
| " |
For
many C# developers, the long wait for optional parameters is over with
C# 4.0. An optional parameter lets you provide a default value and the
caller has a choice of whether or not they want to provide an argument.
In current and earlier versions of C#, you could simulate optional
parameters like this:
// Overload with no parameterpublic static string SayHello(){ return "Hey, You!";}
// Overload with normal parameterpublic static string SayHello(string name){ return "Hey, " + name + "!";}
The
SayHello method above is overloaded with both an empty parameter list
and a parameter list with a single string parameter. To the user of this
code, the name parameter appears to be optional and both of the
following calls work fine:
// Name is optionalvar greetYou = SayHello();
// Can provide name if you wantvar greetJoe = SayHello("Joe");
If
you had methods with more parameters and wanted to provide a more
flexible coding experience, you would provide more overloads. Many
developers have said that this is cumbersome and leaves more code to
maintain. If you’re of the same mind, then you’ll probably be pleased
that C# 4.0 supports optional parameters. The snippet below shows an
optional parameter, replacing the previous two overloads:
// Method with optional parameterpublic static string SayHello(string name = "You"){ return "Hey, " + name + "!";}
As
shown in the previous snippet, the syntax to call an optional parameter
requires assigning a default value to the parameter. In the listing
above, "You" will be assigned to name if the caller does not provide a value.
A feature related to optional parameters is named parameters, which is discussed next.
Named Parameters
One
of the primary purposes of named parameters is that they resolve
ambiguity between parameters. For example, the following method contains
two parameters that are strings:
public static void AddClubMember( string name, string email = "", DateTime? dateJoined = null){ // Not yet implemented}
The types of the first two parameters of the AddClubMember method above are both string, except that name is not optional, but email is optional. This example also demonstrates that you can default parameters to null.
AddClubMember( email: "joe@dot.net", name: "Joe", dateJoined: DateTime.Now);}
The
call to AddClubMember above uses named parameters where the name is the
same as the parameter name in the method declaration with an appended
colon. Notice that I’ve shuffled the parameter order to demonstrate that
you can change the order of parameters.
| " |
Named parameters are particularly useful when you have multiple optional parameters of the same type.
| " |
Named
parameters are particularly useful when you have multiple optional
parameters of the same type. In that case, you name the parameter that
you want to set, telling C# which parameter your argument matches. The
code below demonstrates a problem where named parameters are necessary:
AddClubMember( "joe@dot.net", dateJoined: DateTime.Now);}
If
you recall, the first parameter of the AddClubMember method is name, a
required parameter of type string. Since the first argument above is a
string, C# will match that argument to the name parameter. Clearly, the
value above is an email address, which presents you with a logical error
that won’t be detected at either compile time nor run time when that
line executes.
Posts
