Code - Kennydust

Lambda Expressions

kennydust — Wed, 05 Aug 2009 15:11:00 GMT

This just in: Lambda Expressions are cool.

Yes, I'm a tad late, given that this language feature has been around for some time (introduced originally in .net 3.0, and packaged in .net 3.5). But to my defense, I have these reasons: (1) There wasn’t a need for it on my end, (2) I was working in a .net 2.0 shop, (3) There were so many feature enhancements that this particular one flew under the radar.

Fast forward to today, I've written my first lambda expression and wish to share it.

So what are lambda expressions? In my own words, they are just another way of writing code statements; a shorthand way of encapsulating logic. They can be "expressions" and "statements", and can be assigned to a delegate type. A lambda expression contains a "lambda operator," =>, with the left side of the expression responsible for handling input and the right side containing logic:

  //assuming x equates to a value of 10
  x => x + x;

  (10) => (10) + (10) //equals 20

Below are a few examples I've put together, they are pretty simplified, but it demonstrates how powerful lambda expressions can be. The challenge? Given some DateTime value, perform a comparison to see whether or not this value has exceeded 24 hours.

To start, here’s the original snippet that was coded up.

DateTime expiredTime = DateTime.Parse("1/1/2009"); 
DateTime adjustedTime = DateTime.Now.AddHours(-24);

//original statement 
int comparsionResult = DateTime.Compare(adjustedTime, expiredTime); 
bool isExpired = (comparsionResult > 0);

It's pretty straight forward and it does the job. But we want lambda expressions. Here's an example of that, with an expression that's assigned to a delegate type that expects one input:

delegate bool del(DateTime t); 
static void Main(string[] args)
{
   DateTime expiredTime = DateTime.Parse("1/1/2009"); 
   DateTime adjustedTime = DateTime.Now.AddHours(-24);

   del comparisonDel = x => (DateTime.Compare(adjustedTime, x) > 0);
   bool isExpired = comparisonDel(expiredTime);
}

The second example demostrates wrapping a lambda expression in a Func<> generic delegate.

DateTime expiredTime = DateTime.Parse("1/1/2009"); 
DateTime adjustedTime = DateTime.Now.AddHours(-24);

 //Lambda Expression Wrapped in a Func<>
Func ComparisonCheck = x => (DateTime.Compare(adjustedTime, x) > 0);
bool isExpired = ComparisonCheck(expiredTime);

Validation Application Block

kennydust — Wed, 18 Feb 2009 20:16:00 GMT

How many hours during the day do you sit around and write validation code? Way to many to count, if I'm reading your mind. Validation is pretty common it's in usage that it occurred to me that I needed some sort of compact way of encapsulating rules and business logic. So on my train ride home, I thought to myself -- "Gee, I guess I could create validation attributes, and decorate my properties!" I really thought I was brilliant, and somewhat innovative, but lo and behold, I get home and discover there's already an application block written for just that purpose. So I'm going to entertain myself by writing a use case for this, and post code at the end.

Here's the beauty of the application block: It's flexible. You can decorate your class entities with validation attributes, or validate primitive data types or objects. You can also set up rules via XML, and there's support for ASP.NET, Windows Forms and WCF.

Here's what we would do traditionally:


if (String.IsNullOrEmpty(Textbox1.Text))
{
    throw new ArgumentNullException("No text specified!!");
} else {

    Foo f = new Foo();
    f.bar = TextBox1.Text;
}

Here's how we can solve that with the VAB in code:


StringValidator v = new StringValidator(1, 10);
v.Validate(Textbox1.Text);

//validator would blow up if invalid.. and not execute the next line
Foo f = new Foo();
f.bar = Textbox1.Text;

Here's an alternative way by decorating the property with an attribute:


public class Foo
{
    [StringLengthValidator(1, 50)]
    public string bar
    {
        get;set;
    }
}

This is a very simple usage pattern for what the block can really do; there are Validators that can compare dates, enums and even perform regular expressions. Additionally, you can write you own custom validators, and define more finite rules either inline or using configuration files via XML. It really depends on your business requirements and how crazy you want to extend it. But the point is, you no longer need to stick logic in your website tier.. there's already a framework available that should save your some time.

Here's more information on VAB:

http://msdn.microsoft.com/en-us/library/dd140088.aspx

Download FAB; You can get it as part of the entire Enterprise library that Microsoft releases every now and then:

http://msdn.microsoft.com/en-us/library/cc467894.aspx

You can download my sourcecode example here. Basically the example is a webform for entering your pet information, it performs validation via inline code and makes use of validation attributes. I'm using the Enterprise Library 3.1 - May 2007 version, only because I need .NET framework 2.0 support.

Happy Coding.

StringDictionary will lower your keys (and your expectations)

kennydust — Mon, 02 Feb 2009 17:53:00 GMT

I needed to store a collection of key/value strings, so I turned to a familiar class I've used in the past: System.Collections.Specialized.StringDictionary. It's pretty straightforward to use, you construct it, then add your items one at a time. However, I ran into some pretty odd behavior where all the keys I injected came back out lower cased.. and subsequently, blew up into a nice error screen because some of the underlining code was dependant on specifically cased key strings.

According to microsoft:

The key is handled in a case-insensitive manner; it is translated to lowercase before it is used with the string dictionary.

WTF? There doesn't seem to be any way around it. And I don't see any overloads (StringDictionary has just an empty ctor) or properties to set to override this behavior.. so I may need to find another solution. Microsoft should at least give the developer the option to control how the keys, or values are normalized.

Update: as I was about to submit this entry, I found this blog entry from haack boy. I've resorted to using Dictionary<string, string>.

Dynamic Typing in C# 4.0

kennydust — Tue, 28 Oct 2008 01:44:00 GMT

I'm here at PDC 08 and attended a great session by Anders Hejlsberg for some of the things coming down the pipe for C# 4.0. One of the more exciting offerings is the idea of resolving names in your code at runtime instead of compile time via dynamic lookup. There is a new static Type called dynamic which it's usage pattern is such:

dynamic calc = new Calculator ();
int sum = calc.Add(10, 20);

In addition, it can be used in as a argument modifier for methods:

void RunCalculator(dynamic calc, int num1, int num2)
{
   calc.Add(num1, num2);
}

This is an incredibly powerful feature and Anders himself points out the evolution of C# is in dynamic programming. I guess the initial thought racing through my head is obvious -- what is the performance cost of using dynamics? I've always been against late-binding anything. More thoughts about this later.