I hear C#, I see C#, I do .Net

Anatomy Of Lambda Expressions in C# - for beginners

2007-12-20T15:45:00.001-08:00

I have been examining LINQ and have come to conclusion that parameter signatures can be downright intimidating in LINQ extension methods! The top of my list are the lambda expressions. I am going to attempt to break down on how to "read" the lambda expressions signatures and maybe save you from going mad and blind!

Lets examine this function: f(x,y) = x+y . This function requires two parameters and returns a result of an addition.

To implement function we could try this:

    public static class Calculator
    {
        public static int Add(int x, int y)
        {
            return x + y;
        }
    }

The problem with this implementation is that we actually "implemented" the meaning of the word Add and bound it to a classifier Calculator. What if the name of the method was MySuperAdd? What if the classifier is unknown at the run time? What if we would like to pass add method to another method?

Lambda

In a not so distant past we have been introduced to delegates in C#. Delegate establishes a contract that specifies the signature of one or more methods. Simply said we are informing a compiler to expect a function f with typed parameters and return values. In C++ world this was a function pointer.

Stage 1 - delegate

Lets describe our function with a delegate:

       1: //Function: First Argument Type int, Second Argument Type int, Return Type int

       2: public delegate int AddDelegate(int a, int b);

       3:  

       4: public class Lambda

       5: {

       6:     public static int AddIt(int a, int b) //function described by the delegate; implementation

       7:     {

       8:         return a + b;

       9:     }

      10:  

      11:     public void InvokeDelegate()

      12:     {

      13:         AddDelegate myFunctionPointer = new AddDelegate(AddIt);

      14:         AddDelegate myFunctionPointer2 = new AddDelegate(CalcImpl.Add);

      15:  

      16:         int result = myFunctionPointer(2, 2);

      17:     }

      18:  

      19:     private static class CalcImpl

      20:     {

      21:         public static int Add(int x, int y)

      22:         {

      23:             return x + y;

      24:         }

      25:     }

      26: }

Although this is a contrived example, it shows that I can create instance of delegate pointing to two different function implementations as long as the target method signature is the same as delegate. Line 13 points to Lambda.AddIt method while Line 14 points to CalcImpl.Add method.

Stage 2 - anonymous delegate

Now lets reduce this a bit using the C# anonymous delegates (since v2.0):

       1: //Function: First Argument Type int, Second Argument Type int, Return Type int

       2: public delegate int AddDelegate(int a, int b);

       3:  

       4: public class Lambda

       5: {

       6:     //public static int AddIt(int a, int b) //function described by the delegate; implementation

       7:     //{

       8:     //    return a + b;

       9:     //}

  

    public void InvokeDelegate()

    {

        // inline function implementation and description 

            // a.k.a anonymous delegate

        AddDelegate myFunctionPointer =

                    delegate(int a, int b)

                    {

                        return a + b;

                    };

  

        AddDelegate myFunctionPointer2 =

                    delegate(int a, int b)

                    {

                        return a + b;

                    };

  

        int result = myFunctionPointer(2, 2);

    }

  

}

I have dispensed with internal implementation (lines 6-9) and have moved implementation detail into anonymous delegate (lines 16-19).

Stage 3 - using lambda token =>

Lets further reduce the code by using the shorter syntax. C# introduces a new lambda token "=>". What our delegate describes is two input parameters, a and b (names are purely arbitrary) and return value. Line 14 shows this transformation:

       1: //Function: First Argument Type int, Second Argument Type int, Return Type int

       2: public delegate int AddDelegate(int a, int b);

       3:  

       4: public class Lambda

       5: {

       6:     //public static int AddIt(int a, int b) //function described by the delegate; implementation

       7:     //{

       8:     //    return a + b;

       9:     //}

      10:  

      11:     public void InvokeDelegate()

      12:     {

      13:        //(First Parameter, Second Parameter) => Return 

      14:         AddDelegate myFunctionPointer = (a, b) => a + b;//delegate describing function

      15:  

      16:         int result = myFunctionPointer(2, 2);

      17:     }

      18:  

      19: }

We have dispensed with creating new instance (new AddDelegate) and we have lost the body (the stuff between {} brackets ). Another thing we have lost is explicit declaration of type. The types of input and return parameters will be inferred by compiler, from our delegate definition (line 2). Visual Studio will give you full intellisense support for a and b types.

Stage 4 - dispensing with our delegate

Now if we could somehow describe the function delegate in some generic way... C# has introduced bunch of new generic functions that help with this exact problem.

       1: //Function: First Argument Type int, Second Argument Type int, Return Type int

       2: //public delegate int AddDelegate(int a, int b); //delegate describing function

       3:  

       4: // Already have delegates describing Function with various number of arguments defined

       5: //public delegate TR Func<TR>();

       6: //public delegate TR Func<T0, TR>(T0 a0);

       7:  

       8: //public delegate TR Func<T0, T1, TR>(T0 a0, T1 a1); <-- This one will work for us

       9:  

//public delegate TR Func<T0, T1, T2, TR>(T0 a0, T1 a1, T2 a2);

//public delegate TR Func<T0, T1, T2, T3, TR>(T0 a0, T1 a1, T2 a2, T3 a3);

  

public class Lambda

{

    public static void InvokeDelegate()

    {

        //Func<First Arg Type, Second Arg Type, Return Type>

        Func<int, int, int> myFunctionPointer = (a, b) => a + b; //delegate describing function

  

        int result = myFunctionPointer(2, 2);

    }

  

  

    public static void FancyThis(Func<int, int, int> interesting)

    {

        Func<Func<int, int, int>, int, int> huh = (f, p) => f(p, 3) + p;

  

        int result = huh(interesting, 5);

    }

}

We can completely dispense with our delegate and use one of generic versions of the function declaration (line 8). Lines 24-28 demonstrated the ability to pas the function pointers around and than use them as parameters

Now we can do something like this:

       1: class Program

       2: {

       3:     static void Main(string[] args)

       4:     {

       5:  

       6:         Func<int, int, int> substractor = (a, b) => a - b;

       7:  

       8:         Lambda.FancyThis(substractor);

       9:  

      10:         Func<int, int, int> adder = (a, b) => a + b;

      11:  

      12:         Lambda.FancyThis(adder);

      13:  

      14:     }

      15: }

Don't be intimidated

Some of the method signatures look VERY intimidating especially in LINQ world. For example GroupBy method extensions signature:

public static IEnumerable<IGrouping<TKey, TElement>> GroupBy<TSource, TKey, TElement> (
    IEnumerable<TSource> source,
    Func<TSource, TKey> keySelector,
    Func<TSource, TElement> elementSelector,
    IEqualityComparer<TKey> comparer
)

Is nothing more than a method that returns a list of groups with a key and value; expects four parameters two of them being delegate types and one being a list (source).

First delegate specifies the key for the group (Quantity) while second delegate specifies what value (ProductID, instead of the element of the list) to take and associate with the group. TSource is usually implied from the type on which you are performing group by.

       1: //key, productID

       2: IEnumerable<IGrouping<int, int>> result2 =

       3:    items.GroupBy(

       4:                     keySelector => keySelector.Quantity,

       5:  

       6:                     elementSelector => elementSelector.ProductID //Projection!

       7:                  );

Source in the above case is being implied from items type...

Hopefully this demystifies the lambda expressions a bit and makes your more comfortable breaking down the complex method signatures.

Anatomy Of Lambda Expressions in C# - for beginners

2007-12-10T18:51:00.001-08:00

Lets examine this function: f(x,y) = x+y . This function requires two parameters and returns a result of an addition.

To implement function we could try this:

    public static class Calculator
    {
        public static int Add(int x, int y)
        {
            return x + y;
        }
    }

Lambda

Stage 1 - delegate

Lets describe our function with a delegate:

       1: //Function: First Argument Type int, Second Argument Type int, Return Type int

       2: public delegate int AddDelegate(int a, int b);

       3:  

       4: public class Lambda

       5: {

       6:     public static int AddIt(int a, int b) //function described by the delegate; implementation

       7:     {

       8:         return a + b;

       9:     }

      10:  

      11:     public void InvokeDelegate()

      12:     {

      13:         AddDelegate myFunctionPointer = new AddDelegate(AddIt);

      14:         AddDelegate myFunctionPointer2 = new AddDelegate(CalcImpl.Add);

      15:  

      16:         int result = myFunctionPointer(2, 2);

      17:     }

      18:  

      19:     private static class CalcImpl

      20:     {

      21:         public static int Add(int x, int y)

      22:         {

      23:             return x + y;

      24:         }

      25:     }

      26: }

Stage 2 - anonymous delegate

Now lets reduce this a bit using the C# anonymous delegates (since v2.0):

       1: //Function: First Argument Type int, Second Argument Type int, Return Type int

       2:     public delegate int AddDelegate(int a, int b);

       3:  

       4:     public class Lambda

       5:     {

       6:         //public static int AddIt(int a, int b) //function described by the delegate; implementation

       7:         //{

       8:         //    return a + b;

       9:         //}

  

        public void InvokeDelegate()

        {

            AddDelegate myFunctionPointer =

                new AddDelegate

                    (

                // inline function implementation and description 

                // a.k.a anonymous delegate

                        delegate(int a, int b)

                        {

                            return a + b;

                        }

                    );

  

            AddDelegate myFunctionPointer2 =

                new AddDelegate

                    (

                // inline function implementation and description 

                // a.k.a anonymous delegate

                        delegate(int a, int b)

                        {

                            return a + b;

                        }

                    );

  

            int result = myFunctionPointer(2, 2);

        }

  

    }

I have dispensed with internal implementation (lines 6-9) and have moved my implementation directly inside the constructor of the new delegate (lines 18-21). We have not gained much except that our implementation seems more inline.

Stage 3 - using lambda token =>

       1: //Function: First Argument Type int, Second Argument Type int, Return Type int

       2: public delegate int AddDelegate(int a, int b);

       3:  

       4: public class Lambda

       5: {

       6:     //public static int AddIt(int a, int b) //function described by the delegate; implementation

       7:     //{

       8:     //    return a + b;

       9:     //}

      10:  

      11:     public void InvokeDelegate()

      12:     {

      13:        //(First Parameter, Second Parameter) => Return 

      14:         AddDelegate myFunctionPointer = (a, b) => a + b;//delegate describing function

      15:  

      16:         int result = myFunctionPointer(2, 2);

      17:     }

      18:  

      19: }

Stage 4 - dispensing with our delegate

Now if we could somehow describe the function delegate in some generic way... C# has introduced bunch of new generic functions that help with this exact problem.

       1: //Function: First Argument Type int, Second Argument Type int, Return Type int

       2: //public delegate int AddDelegate(int a, int b); //delegate describing function

       3:  

       4: // Already have delegates describing Function with various number of arguments defined

       5: //public delegate TR Func<TR>();

       6: //public delegate TR Func<T0, TR>(T0 a0);

       7:  

       8: //public delegate TR Func<T0, T1, TR>(T0 a0, T1 a1); <-- This one will work for us

       9:  

//public delegate TR Func<T0, T1, T2, TR>(T0 a0, T1 a1, T2 a2);

//public delegate TR Func<T0, T1, T2, T3, TR>(T0 a0, T1 a1, T2 a2, T3 a3);

  

public class Lambda

{

    public static void InvokeDelegate()

    {

        //Func<First Arg Type, Second Arg Type, Return Type>

        Func<int, int, int> myFunctionPointer = (a, b) => a + b; //delegate describing function

  

        int result = myFunctionPointer(2, 2);

    }

  

  

    public static void FancyThis(Func<int, int, int> interesting)

    {

        Func<Func<int, int, int>, int, int> huh = (f, p) => f(p, 3) + p;

  

        int result = huh(interesting, 5);

    }

}

Now we can do something like this:

       1: class Program

       2: {

       3:     static void Main(string[] args)

       4:     {

       5:  

       6:         Func<int, int, int> substractor = (a, b) => a - b;

       7:  

       8:         Lambda.FancyThis(substractor);

       9:  

      10:         Func<int, int, int> adder = (a, b) => a + b;

      11:  

      12:         Lambda.FancyThis(adder);

      13:  

      14:     }

      15: }

Don't be intimidated

Some of the method signatures look VERY intimidating especially in LINQ world. For example GroupBy method extensions signature:

public static IEnumerable<IGrouping<TKey, TElement>> GroupBy<TSource, TKey, TElement> (
    IEnumerable<TSource> source,
    Func<TSource, TKey> keySelector,
    Func<TSource, TElement> elementSelector,
    IEqualityComparer<TKey> comparer
)

Is nothing more than a method that returns a list of groups with a key and value; expects four parameters two of them being delegate types and one being a list (source).

       1: //key, productID

       2: IEnumerable<IGrouping<int, int>> result2 =

       3:    items.GroupBy(

       4:                     keySelector => keySelector.Quantity,

       5:  

       6:                     elementSelector => elementSelector.ProductID //Projection!

       7:                  );

Source in the above case is being implied from items type...

Hopefully this demystifies the lambda expressions a bit and makes your more comfortable breaking down the complex method signatures.

EXECUTE AS clause (TSQL)

2007-07-20T13:09:00.001-07:00

"By specifying the context in which the module is executed, you can control which user account the SQL Server 2005 Database Engine uses to validate permissions on objects that are referenced by the module." - BOL

The Options

{ EXEC | EXECUTE } AS { CALLER | SELF | OWNER | 'user_name' }

This applies to create procedure statement:

SQL 2000->2005 migration

2007-07-19T10:13:00.000-07:00

Breaking Changes to Database Engine Features in SQL Server 2005

Behavior Changes to Database Engine Features in SQL Server 2005

2007-07-19T07:52:00.001-07:00

The 10 mistakes that put projects at risk of failure include:

* Never committing to project success.

* Freezing the schedule and budget before a project is sufficiently understood.

* Overscoping a solution.

* Circumventing the application development organization altogether.

* Underestimating the complexity of a problem.

* Being stingy with subject-matter experts, in which their participation is not sufficient.

* Choosing the wrong project leadership.

* Distrusting managers who have had tasks delegated to them.

* Jumping into development without enough research.

* Suppressing bad news, in which dialogue is insufficient.

Forrester Research

What OS is on your development box?

2007-06-20T21:51:00.001-07:00

I think its about time MS comes up with Windows Developer version of their OS.

Windows XP is not a development platform because it does not "closely" resemble the production boxes. If we are running W2003K server and developing on XP you can't truly have accurate testing environment.

My standard requirement is that all developers run W2003K servers on their boxes.

Am I alone one this one?

Technorati Tags: Development General

WCF - for VS 2005 resources

2007-06-20T20:59:00.001-07:00

For us mere mortals who are not running the bleeding edge software...

For all the rest of the world which is not running Vista here is what you need to get going with WCF on your XP/2003 box:

Visual Studio 2005
Windows SDK aka Microsoft® Windows® Software Development Kit for Windows Vista™ and .NET Framework 3.0 Runtime Components (you will need the SvcUtil that is buried there)
3.0 Fx
IDesign tons of examples from Juval
Michele's (That Indigo Girl) blog
How to control namespaces from Kirill
All you wanted to know about <system.serviceModel> config settings on MSDN
Java interoperability

WCF (and WPF) extensions Nov 2006 CTP (Not sure how current this is)
Guidance Automation Packages
WCF Service Factory (amongst others)

I'll Keep adding as I discover more. I just can't find the intellisense schema files that would be useful when playing around with the .config file and <system.serviceMode> config settings. One can use the ServiceConfig utility from the SDK.

{UPDATE} When WinSDK is installed the intellisense schemash for WCF config files show up.

Technorati Tags: .NET, WCF, Visual Studio 2005

Share this post :

Monitors

2007-06-15T16:21:00.001-07:00

Petar

Vertical monitors are AWESOME! My new 24" wide nonitors.

Bloom Filter

2007-06-15T14:56:00.001-07:00

Very fascinating reading.

"The Bloom filter, conceived by Burton H. Bloom in 1970, is a space-efficient probabilistic data structure that is used to test whether an element is a member of a set. False positives are possible, but false negatives are not. Elements can be added to the set, but not removed (though this can be addressed with a counting filter). The more elements that are added to the set, the larger the probability of false positives." -- Wikipedia

Also you can find a good examples in C# by Jim Mischel

Some of my own testing for 400,000 items insert requires 2,104,541 bits array. False positives for this large number of tests is kept at 2.4% which is amazing.

You can find out these numbers with Bloom Filter Calculator by Panagiotis (Pete) Manolios.

Technorati Tags: C#, Very Large Data Structures (VLDS)

TechEd

2007-06-14T20:06:00.000-07:00

TechEd was big. Lots of sessions. It could have lasted for at least four weeks.

What I took from TechEd is my renewed interest to Spring.Net framework, which closely matches what I wanted COM+ to be. The only missing piece of the puzzle is the hosting that might be solved with the WAS.

I liked System Center and how it can be wired into instrumented applications. I had only brief look at it but it looks very promising.

I was surprised how well attended were the architecture sections, almost always full.Wish I had more time for XAML, SharePoint and SOA track but I will be satisfied by slides for now.

Comment on 100 patterns every developer should know

2007-02-25T21:25:00.000-08:00

I always find it interesting that we think most developers are capable of following or recognizing a good design. Nick sugests that there are potential 100 essential patterns that each developer should know. I think patterns are far beyond hard for an average developer.

As my favorite software legend Juval Lowy of IDesign would say "its all plumbing". This plumbing should be left for people like Juval. So what is the solution? It depends (Juval's favorite).

If we can progress from Assembler to C/C++ to managed code, shouldn't we be able to do something similar and eliminate patterns completly?

Noteworthy Feb, 2007

2007-02-23T11:55:00.000-08:00

Remote Desktop Connection 6.0 client update is available for download in the Microsoft Download Center
http://support.microsoft.com/kb/925876

Hawkeye - The .Net Runtime Object Editor
http://www.acorns.com.au/Projects/Hawkeye/

http://jayflowers.com/joomla/index.php?option=com_content&task=view&id=13&Itemid=38

.NET Application Extensibility
http://msdn.microsoft.com/msdnmag/issues/07/02/CLRInsideOut/default.aspx

PageAsyncTask Class (not for the novice developer)
http://msdn2.microsoft.com/en-us/library/system.web.ui.pageasynctask(VS.80).aspx

User Interface Process Application Block - Version 2.0
http://www.microsoft.com/downloads/details.aspx?familyid=98c6cc9d-88e1-4490-8bd6-78092a0f084e&displaylang=en&tm

howard gardner, multiple intelligences and education
http://www.infed.org/thinkers/gardner.htm#multiple_intelligences