Partial Methods

One feature that you may have not heard of yet is a feature called partial methods. This is some of the work that I did in the last coding milestone a few months back. Partial methods are methods that enable lightweight event handling. Here is an example declaration:

partial class C
{
static partial void M(int i);
}

There are a few notable things here:

1. Partial methods must be declared within partial classes

2. Partial methods are indicated by the partial modifier

3. Partial methods do not always have a body (well look at this more below)

4. Partial methods must return void

5. Partial methods can be static

6. Partial methods can have arguments (including this, ref, and params modifiers)

Now suppose that I make a call to C.M.

partial class C
{

static void Main()
{
C.M(Calculation());
}
}

Since M has no body, all calls to C.M are removed at compile time as well as the evaluation of the arguments. So the above program is equivalent to:

partial class C
{

static void Main()
{
}
}

In this sense, partial methods are the distant cousins of conditional methods which also sometimes remove the call and the evaluation of the arguments. But partial methods go even further. When a partial method has no body then the partial method is not even emitted to metadata.

So far this might seem a little confusing. C# now allows users to declare methods for which the calls, the evaluation of the arguments, and the method itself are not emitted. Fortunately, the story doesn’t end there. Partial methods allow users to define a body for the method so that the method, the calls, and the evaluation of the arguments are emitted.

partial class C
{
static partial void M(int i); // defining declaration
static partial void M(int i) // implementing declaration
{
}
}

In the code above, we see that there is a difference between a defining declaration of a partial method and an implementing declaration of a partial method and the difference is whether or not the method has a body. These definitions don’t have to be in the same partial class declaration. There may only be one defining declaration and if a defining declaration exists then there may be an implementing declaration.

Why Partial Methods?

So how are these partial methods used? The common scenario is to use them to do lightweight event handling. For example a tool that generates code may wish to have hooks for users to customize what code is run. For example, imagine that a tool generated a bunch of code for a class representing a customer. It might look like this:

partial class Customer
{
string name;

public string Name
{
get
{
return name;
}
set
{
OnBeforeUpdateName();
OnUpdateName();
name = value;
OnAfterUpdateName();
}
}

partial void OnBeforeUpdateName();
partial void OnAfterUpdateName();
partial void OnUpdateName();
}

If the user doesn’t add any implementing definitions then this code is equivalent to:

partial class Customer
{
string name;

public string Name
{
get
{
return name;
}
set
{
name = value;
}
}

}

No extra metadata for things that are not used and no extra instructions for useless operations. On the other hand if the user listened to the OnUpdateName “event” like this:

partial class Customer
{
partial void OnUpdateName()
{
DoSomething();
}
}

Then the original definition is equivalent to:

partial class Customer
{
string name;

public string Name
{
get
{
return name;
}
set
{
OnUpdateName();
name = value;
}
}

partial void OnUpdateName();
}

Comparing Partial Methods to the Alternatives

At this point, it is sensible to ask why not just use subclassing and virtual methods? Of course, this would also work but it does have the drawback that the calls, the methods, and the evaluation of the arguments will still be emitted even if the virtual methods are not overridden. So in a system like Linq to SQL that has thousands of little events it allows these events to be very lightweight so that the user only pays for those events that she uses.

A Few Fine Points

Consider the following program…

partial class C
{
static void Main()
{
int i = 3;
C.M(i = 5);
Console.WriteLine(i);
}
}

What does it write to the console? 3, 5, …?

Actually, it is impossible to tell from just this code. If there is no implementing declaration then the program will display 3 because the i = 5 will never be evaluated, but if there is an implementing declaration then the program will display 5. The same is true for conditional methods. So if you want a side-effect to occur make sure you do not cause the side-effect to occur as an argument to a partial method. Of course, the same trick can be used to hide expensive calculations.

partial class C
{
static void Main()
{
C.M(VeryVeryExpensiveCalculation());
}
}

If there is no implementing declaration then the very very expensive calculation will never be performed.

Now what about attributes, how does those work?

partial class D
{
[W]
[return:X]
partial void M([Z]int foo)
{
}

[Z]
[return:W]
partial void M([Y]int foo);
}

What attributes are actually emitted on M? W and Z are the attributes on M; X and W are the attributes on the return type; Y and X are the attributes on the type parameter; Z and Y are the attributes on the parameter.

read original

Scott is providing us with series of lessons about newly developed Orcas features. This time its time for Anonymous Types. Let see what his post is about:

What are Anonymous Types?

Anonymous types are a convenient language feature of C# and VB that enable developers to concisely define inline CLR types within code, without having to explicitly define a formal class declaration of the type.

Anonymous types are particularly useful when querying and transforming/projecting/shaping data with LINQ.

Anonymous Type Example

In my previous Query Syntax blog post I demonstrated how you could transform data with projections. This is a powerful feature of LINQ that enables you to perform query operations on a data source (regardless of whether it is a database, an XML file, or an in-memory collection), and shape the results of the data being queried into a different structure/format than the original data source is in.

In my previous Query Syntax blog post I defined a custom “MyProduct” class that I used to represent my transformed product data. By explicitly defining the “MyProduct” class I have a formal CLR type contract that I can use to easily pass my custom-shaped product results between web-services or between multiple classes/assemblies within my application solution.

However, there are times when I just want to query and work with data within my current code scope, and I don’t want to have to formally define an explicit class that represents my data in order to work with it. This is where anonymous types are very useful, as they allow you to concisely define a new type to use inline within your code.

For example, assume I use the LINQ to SQL object relational mapper designer within “Orcas” to model the “Northwind” database with classes like below:

I can then use the below code to query the Product data in my database, and use the projection/transformation capability of LINQ to custom shape the data result to be something other than the “Product” class above. Rather than use an explicitly defined “MyProduct” class to represent each custom-shaped row of data retrieved from the database, I can instead use the anonymous type feature to implicitly define a new type with 4 properties to represent my custom shaped data like so:

In the code above I’m declaring an anonymous type as part of the select clause within my LINQ expression, and am having the compiler automatically create the anonymous type with 4 properties (Id, Name, UnitPrice and TotalRevenue) – whose property names and type values are inferred from the shape of the query.

I’m then using the new “var” keyword within C# to programmatically refer to the IEnumerable sequence of this anonymous type that is returned from the LINQ expression, as well as to refer to each of the anonymous type instances within this sequence when I programmatically loop over them within a foreach statement later in my code.

While this syntax gives me dynamic language-like flexibility, I also still retain the benefits of a strongly-typed language – including support for compile-time checking and code intellisense within Visual Studio. For example, notice above how I am doing a foreach over the returned products sequence and I am still able to get full code intellisense and compilation checking on the anonymous type with custom properties that was inferred from the LINQ query.

Understanding the Var Keyword

C# “Orcas” introduces a new var keyword that may be used in place of the type name when performing local variable declarations.

A common misperception that people often have when first seeing the new var keyword is to think that it is a late-bound or un-typed variable reference (for example: a reference of type Object or a late-bound object like in Javascript). This is incorrect — the var keyword always generates a strongly typed variable reference. Rather than require the developer to explicitly define the variable type, though, the var keyword instead tells the compiler to infer the type of the variable from the expression used to initialize the variable when it is first declared.

The var keyword can be used to reference any type in C# (meaning it can be used with both anonymous types and explictly declared types). In fact, the easiest way to understand the var keyword is to look at a few examples of it using common explict types. For example, I could use the var keyword like below to declare three variables:

The compiler will infer the type of the “name”, “age” and “male” variables based on the type of their initial assignment value (in this case a string, an integer, and a boolean). This means it will generate IL that is absolutely identical to the code below:

The CLR actually never knows that the var keyword is being used – from its perspective there is absolutely no difference between the above two code examples. The first version is simply syntactic sugar provided by the compiler that saves the developer some keystrokes, and has the compiler do the work of inferring and declaring the type name.

In addition to using built-in datatypes with the var keyword, you can obviously also use any custom types you define. For example, I could go back to the LINQ query projection I did in my previous blog post that used an explicit “MyProduct” type for the data-shaping and adapt it to use the var keyword like so:

Important: Although I’m using the “var” keyword above, I’m not using it with an anonymous type. My LINQ query is still shaping the returned data using the “MyProduct” type – which means that the “var products” declaration is simply a shorthand for “IEnumerable products”. Likewise, the “var p” variable I defined within my foreach statement is simply shorthand for a a variable of type “MyProduct p”.

Important Rule about the Var Keyword

Because the var keyword produces a strongly-typed variable declaration, the compiler needs to be able to infer the type to declare based on its usage. This means that you need to always do an initial value assignment when declaring one. The compiler will produce a compiler error if you don’t:

Declaring Anonymous Types

Now that we’ve introduced the “var” keyword, we can start to use it to refer to anonymous types.

Anonymous types in C# are defined using the same object initializer syntax I covered in my first blog post in this language series. The difference is that instead of declaring the type-name as part of the initialization grammar, when instantiating anonymous types you instead just leave the type-name blank after the “new” keyword:

The compiler will parse the above syntax and automatically define a new standard CLR type that has 4 properties. The types of each of the 4 properties are determined based on the type of the initialization values being assigned to them (for example: in the sample above the “Id” property is being assigned an integer – so the compiler will generate the property to be of type integer).

The actual CLR name of the anonymous type will automatically be generated by the C# compiler. The CLR itself actually doesn’t know the difference between an anonymous type and a named type – so the runtime semantics of the two are absolutely identical. Bart De Smet has a good blog post here that details this if you want to see the exact class name pattern and IL generated.

Note above how when you type “product.” on the anonymous type, you still get compile-time checking and full intellisense within Visual Studio. Notice also how the intellisense description indicates it is an “AnonymousType” – but still provides full declaration information of the properties (this is the text circled in red).

Using Anonymous Types for Hierarchical Shaping

One of the powerful scenarios that anonymous types makes easy is the ability to easily perform hierarchical shape projections of data with a minimum amount of code.

For example, I could write the below LINQ expression to query all products from the Northwind database whose price is greater than $50, and then shape the returned products in a hierarchical structure sorted by the Products’ stock reorder level (using the “group into” clause supported by LINQ query syntax):

When the above code is run in ASP.NET, I’ll get the below output rendered in my browser:

I could likewise do nice hierarchical shapings based on JOIN results. For example, the below code creates a new anonymous type with some standard product column properties, as well as a hierarchical sub-collection property that contains the orderdetails of the 5 most recent orders that customers have placed for that particular product:

Notice how I can neatly traverse the hierarchical data. Above I’m looping over the product query, and then drilling into the collection of the last 5 orders for each product. As you can see, I have full intellisense and compile-time checking everywhere (even on properties of objects within the nested sub-collection of order details on the anonymous type).

Data Binding Anonymous Types

As I mentioned earlier in this blog post, there is absolutely no difference from a CLR perspective between an anonymous type and an explicitly defined/named type. Anonymous types and the var keyword are purely “syntactic sugar” that avoid you having to type code – the runtime semantics are the same as using explicitly defined types.

Among other things, this means that all of the standard .NET type reflection features work with anonymous types – which means that features like databinding to UI controls work just fine with them. For example, if I wanted to display the results of my previous hierarchical LINQ query, I could define an control within a .aspx page like below:

The .aspx above contains a gridview with 2 standard boundfield columns, and one templated field column that contains a nested control that I’ll use to display the product’s hierarchical orderdetail sub-results.

I could then write the below LINQ code to perform my hierarchical query against the database and databind the custom-shaped results against the GridView to display:

Because the GridView supports binding against any IEnumerable sequence, and uses reflection to retrieve property values, it will work just fine against the anonymous type I’m using above.

At runtime the above code will produce a simple grid of product details with a hierarchical list of their recent order quantities like so:

Obviously you could make this report much richer and prettier – but hopefully you get the idea of how easy it is to now perform hierarchical queries against a database, shape the returned results however you want, and then either work against the results programmatically or databind them to UI controls.

Summary

Anonymous types are a convenient language feature that enable developers to concisely define inline CLR types within code, without having to explicitly provide a formal class declaration of the type. Although they can be used in lots of scenarios, there are particularly useful when querying and transforming/shaping data with LINQ.

This post concludes my 5-part language series for “Orcas”. Going forward I’ll be doing many more LINQ posts that will demonstrate how to actually take advantage of all of these new language features to perform common data access operations (defining data models, querying, updating, using sprocs, validation, etc). I wanted to get this 5 part language series done first, though, so that you’ll have a good way to really understand the underlying language constructs as we drill into scenarios within my upcoming posts.

view original

Scott Guthrie is as usually explaining the new features of the new Orcas Studio. This time he looks over the Lambda Expressions. Up to now they arent supported in VB but only in C#. Looking forward to see them in VB!

So here is what Scott wrote:

“What are Lambda Expressions?

Lambda Expressions provide a more concise, functional syntax for writing anonymous methods. They end up being super useful when writing LINQ query expressions – since they provide a very compact and type-safe way to write functions that can be passed as arguments for subsequent evaluation.“
view original