Lazy Evaluation example:

In a previous post I talked about C# Actions and how they are a useful feature that could provide new shorthand for lazy evaluation. I have since found an excellent article [1] which demonstrates lazy evaluation with LINQ. The advantages in that article show how LINQ queries can minimize memory usage by evaluating upon enumeration rather than just allocating memory for everything the query would return.

Func

Actions are delegates that have a void return type. This makes sense if you are using Actions as event handlers, but for other use cases you will want a return type. In these cases you will want to use Func. One issue I have seen with Func is when you want don’t know how many parameters your function is going to take. If the number is variable then you must implement up to the amount of parameters you want (if overloading). I noticed a few examples of that in the Ninject 1.x source code. To generalize Func and Actions you can use the ‘Delegate’ type (note: the captialization).

A real world use case

A reason for lazy evaluation could be that you want to perform a group of service calls at one time. The service calls could be a transaction style interaction which would want to be disposed afterwards and some of the service calls could be surplus to requirement. If I had a user interface which required a list of products to be loaded, then that screen may not need that data reloaded if it is moving from a screen which has that data loaded. That service call could be pre-evaluated (ie lazy evaluation) to check to see if it is necessary.

As a fan of ObservableCollections, I have created an observable dictionary. I have provided the code below. I have implemented interfaces that should allow for WPF databinding. The reason I needed such a class is because I needed an event to indicate when the dictionary was updated. I kept this class small (it is just a wrapper over a dictionary).

public class ObservableDictionary<TKey, TValue> :

        IDictionary<TKey, TValue>,

        INotifyCollectionChanged,

        INotifyPropertyChanged

{

    public event NotifyCollectionChangedEventHandler CollectionChanged;

    public event PropertyChangedEventHandler PropertyChanged;

 

    readonly IDictionary<TKey, TValue> _dictionary = new Dictionary<TKey, TValue>();

 

    public IEnumerator<KeyValuePair<TKey, TValue>> GetEnumerator()

    {

        return _dictionary.GetEnumerator();

    }

 

    IEnumerator IEnumerable.GetEnumerator()

    {

        return GetEnumerator();

    }

 

    public void Add(KeyValuePair<TKey, TValue> item)

    {

        _dictionary.Add(item);

 

        if (CollectionChanged != null)

            CollectionChanged(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Add));

 

        if (PropertyChanged != null)

        {

            PropertyChanged(this, new PropertyChangedEventArgs("Keys"));

            PropertyChanged(this, new PropertyChangedEventArgs("Values"));

        }

    }

 

    public void Clear()

    {

        int keysCount = _dictionary.Keys.Count;

 

        _dictionary.Clear();

 

        if (keysCount == 0) return; //dont trigger changed event if there was no change.

 

        if (CollectionChanged != null)

            CollectionChanged(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset));

 

        if (PropertyChanged != null)

        {

            PropertyChanged(this, new PropertyChangedEventArgs("Keys"));

            PropertyChanged(this, new PropertyChangedEventArgs("Values"));

        }

    }

 

    public bool Contains(KeyValuePair<TKey, TValue> item)

    {

        return _dictionary.Contains(item);

    }

 

    public void CopyTo(KeyValuePair<TKey, TValue>[] array, int arrayIndex)

    {

        _dictionary.CopyTo(array, arrayIndex);

    }

 

    public bool Remove(KeyValuePair<TKey, TValue> item)

    {

        bool remove = _dictionary.Remove(item);

 

        if (!remove) return false; //don’t trigger change events if there was no change.

 

        if (CollectionChanged != null)

            CollectionChanged(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Remove));

 

        if (PropertyChanged != null)

        {

            PropertyChanged(this, new PropertyChangedEventArgs("Keys"));

            PropertyChanged(this, new PropertyChangedEventArgs("Values"));

        }

 

        return true;

    }

 

    public int Count

    {

        get { return _dictionary.Count; }

    }

 

    public bool IsReadOnly

    {

        get { return _dictionary.IsReadOnly; }

    }

 

    public bool ContainsKey(TKey key)

    {

        return _dictionary.ContainsKey(key);

    }

 

    public void Add(TKey key, TValue value)

    {

        _dictionary.Add(key, value);

 

        if (CollectionChanged != null)

            CollectionChanged(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Add));

 

        if (PropertyChanged != null)

        {

            PropertyChanged(this, new PropertyChangedEventArgs("Keys"));

            PropertyChanged(this, new PropertyChangedEventArgs("Values"));

        }

    }

 

    public bool Remove(TKey key)

    {

        bool remove = _dictionary.Remove(key);

 

        if (!remove) return false;

 

        if (CollectionChanged != null)

            CollectionChanged(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Remove));

 

        if (PropertyChanged != null)

        {

            PropertyChanged(this, new PropertyChangedEventArgs("Keys"));

            PropertyChanged(this, new PropertyChangedEventArgs("Values"));

        }

 

        return true;

    }

 

    public bool TryGetValue(TKey key, out TValue value)

    {

        return _dictionary.TryGetValue(key, out value);

    }

 

    public TValue this[TKey key]

    {

        get { return _dictionary[key]; }

        set

        {

            bool changed = _dictionary[key].Equals(value);

 

            if (!changed) return; //if there are no changes then we don’t need to update the value or trigger changed events.

 

            _dictionary[key] = value;

 

            if (CollectionChanged != null)

                CollectionChanged(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Replace));

 

            if (PropertyChanged != null)

            {

                PropertyChanged(this, new PropertyChangedEventArgs("Keys"));

                PropertyChanged(this, new PropertyChangedEventArgs("Values"));

            }

        }

    }

 

    public ICollection<TKey> Keys

    {

        get { return _dictionary.Keys; }

    }

 

    public ICollection<TValue> Values

    {

        get { return _dictionary.Values; }

    }

}

 

A link to another (Larger) implementation of an Observable Dictionary: http://www.drwpf.com/Blog/Default.aspx?tabid=36&EntryID=8

To the extent possible under law, Richard Wilburn has waived all copyright and related or neighboring rights to Observable Dictionary. This work is published from New Zealand.

When playing around with UI events it is sometimes handy to use lambda notations of actions to do a tidy inline event-action handler definition such as:

Button1.Click += (sender, args) => Debug.WriteLine("Button Click");

If we delve a little deeper into Actions, we can use them to pass around code snippets/functions.

Action<String> action = (input) => Debug.WriteLine("Testing" + input); 

I have heard many arguments against functional features such as actions in C# however I do feel that they are very useful in edge cases. One such case could be the mass adding of items to a dictionary, such as:

var namesDictionary = new Dictionary<int, string>();

namesDictionary.Add(1,"One");

namesDictionary.Add(2,"Two");

namesDictionary.Add(3,"Three");

If we wanted to keep our code maintainable we might want to reduce our dependency to the Add method (especially if we had lots of dictionary add statements).

Action<int,string> addAction = (key,value) => namesDictionary.Add(key,value);

//Action<int,string> addAction = namesDictionary.Add; //short syntax

addAction(1, "One");  //etc

Note that this dictionary example is a bad example as the collection initialization could be used here which is likely the most optimal solution. The following shows how the collection initialization could have been used:

var namesDictionary = new Dictionary<int, string> {{1, "One"}, {2, "Two"}, {3, "Three"}};

This example also could have been solved more optimally using extension method(s), by extending the dictionary, dependency injection, lambda foreach statement, foreach loop etc. With that said, Actions are important in allowing for lazy evaluation/delayed invocation. I am not going to get into lazy evaluation in this post, but I recommend checking out the Haskell language community for lazy evaluation ideas. I highly recommend the following link for understanding how evaluation/manipulation of lambda expressions work.

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

Remedies:

Visual Studio has always worked fairly well for me at home, but at work where many of our projects/solutions are very large Visual Studio struggles. At home I still find that my Visual Studio is better than the one I use at work and I believe this is because at home I have my hard-drives in a performance RAID (Raid 0) and my OS is Vista x64 rather than XP x86.

Two things I suspect are:

Vista manages memory much better and doesn’t struggle with the out of memory exceptions that I frequently get at work. Note: Out of memory exceptions are actually to do with the .NET runtime not being able to garbage collect all of its generations properly. But the size of Visual Studio and the number of objects it is using is the cause of this.

Hard-drive speed affects Visual Studio more greatly than CPU and potentially even RAM. When I get out of memory exceptions at work (we all get this too btw) my PC is not using all of its 2 gigs of ram. Visual Studio is limited by default to 2 gigs, but this can be overcome.

 

Faster harddrives, lowerlatency hard drives:

On Vista with my RAID 0 my experience is better but is still latent. My IDE can load lots of data fast but often takes a while to do so. This means waits are still a small amount of time due to latency issues but large amounts of data are not really an issue.

I am starting to think that the ideal solution is a performance raid of Solid State Drives (SSD).  A link on performance improvements for a Java IDE are available here: http://jexp.de/blog/archives/18-On-Boosting-My-IDEA-Jetbrains-IntelliJ-IDEA-is-fast-again.html

If you have an infinite money pool, a RAID card would be recommended too. These can have RAM on them to cache disk access which would further reduce latency.

Upgrade OS:

Upgrade to Vista and make sure you upgrade to the 64 bit version. It is silly not to take advantage of your CPU being x64.

Myths:

 

Resharper:

Myth: Reshaper significantly degrades performance, and causes out of memory exceptions.

Interestingly resharper shows the out of memory exceptions (which can be a pain) where as Visual Studio virtually hides it from the user. Resharper is not causing these issues, and from what I have seen there is no significant performance difference apart from when the project is being loaded. That is because resharper loads its cache then by analysing assemblies.

RAM:

Myth: Increasing RAM will increase Visual Studio’s performance

I think that if Visual Studio is running out of memory then a RAM increase will help, but for us at work our RAM is not being fully utilized so on XP increasing our RAM won’t help us as the OS will not use it. On Vista however the OS endeavours to use as much free RAM as it can to cache and pre-allocate so it is possible this will help a little bit. I think the biggest myth about personal computing is that upgarding CPU and RAM makes the biggest difference. My computer at home is 4 years old and my computer at work is 6 months old. My computer at home that is 4 years old is faster in practical usage. If it came down to a number crunching war then the new computer would win but there is virtually no use case for that in personal computing.

I have to confess I am enjoying lambdas a bit much. I am making this post to show a cool way of avoiding code loops (there are still loops in CLR of course).

private void UpdatePerson(Person updatedPersonObject)

{

    var outOfDatePerson = _people

            .First(person => person.Id == updatedPersonObject.Id);

    int index = _people.IndexOf(outOfDatePersonObject);

    _people[index] = updatedPersonObject;

}

private void UpdatePerson_OldCSharp(Person updatedPersonObject)

{

    int outOfDatePersonIndex = 0;

    for (int i = 0; i < _people.Count ; i++ )

    {

        if (_people[i].Id == updatedPersonObject.Id)

        {

            outOfDatePersonIndex = i;

            break;

        }

    }

    _people[outOfDatePersonIndex] = updatedPersonObject;

}

 

From the two code samples it is worth noticing the difference in the number of lines and in the hierarchical nature of the code. The traditional C# for loop approach (the second method) leads me to cringe from a maintenance point of view. Each line of code is highly contextual and relies heavily on multiple levels of language constructs.

The first method (the lambda way) to me is much more readable and also maintainable. There is a flat hierarchy which is much easier to read as it doesn’t involve following the loop through code. I argue it is easier to maintain as the lines can change order more and will still be doing the same thing. It is also easier to update as there is less code.

If you use WPF then you will be using databinding extensively. This post looks at databinding with respect to collections.

Databinding basics (Background Info):

To databind in .NET currently you are required to provide notification of when the variables you databind to change. This can be done by implementing the INotifyPropertyChanged interface or by implementing the property as a dependency property. For more information on databinding basics, see here.

Collections are slightly different

In the case of collections it is often not important when a collection object changes but rather when the items within that collection change. With that said you will likely need both approaches implemented because if an entire collection is reassigned the binding to the observable collection will be lost as it has been replaced with a new observable collection. It is also possible that others in your team will re-assign the list at some point, so that is why I like to plan for that situation.

private ObservableCollection<String> _names;

internal ObservableCollection<String> Names

{

    get { return _names; }

    set

    {

        _names = value;

        PropertyChanged(this, new PropertyChangedEventArgs("Names"));

    }

}

 

ObservableCollection<T> notifies bindings an item has changed from its CollectionChanged event. The previous code sample shows the INotifyPropertyChanged interface implementation which is required to see if the ObservableCollection assigned to “Names” has been changed. 

In conclusion all Lists that are going to be used for databinding should be ObservableCollections. All properties that are databinded to should implement the INotifyPropertyChanged interface or be dependency properties.

I am no expert with databases, however I can definitely see scalability issues that relational databases provide when needed to grow beyond one database. Relational databases also are strongly typed and explicit relationships exist between entities. This explicit relationship specification and strong typing often requires developers to write migration scripts which can be a pain and could potentially be avoided or minimized.

There is an interesting article: http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php which discusses the benefits of key-value databases or cloud oriented databases.

Unfortunately most of these databases are in beta and the standards between them are lacking, but I can definitely see from my experience developing payroll software that a key-value database would help us in many areas.

The down sides to key-value databases are that they are weakly typed and hence there is no schema which means you can get bad data in the database, meaning that code has to deal with that possibility, which could lead to more mistakes. I do feel however that weaker typing and not specifying relationships between entities is the way of the future because if we look at C# and other modern languages we can notice a trend of moving towards more weakly typed languages.

I do prefer a strongly typed language currently however as technology progresses I can see that dynamic typing will lead to more general code that will be more flexible to change. Currently my biggest concern is that dynamically typed languages are prone to catching errors at runtime rather than compile time which is a blow for software reliability. I am confident that this can be overcome.

It is important to state that there is an overhead in specifying types/schemas and converting between types. I also think that currently developers can make assumptions in strongly typed languages that objects will be populated in a way that they expect which sometimes is not the case. With dynamically typed objects this assumption would not be exercised as it would soon become clear that less can be assumed. The immediate development areas of .NET CLR 3.5 and 4.0 show that functional programming and dynamic objects are the current direction. I also like the hybrid approach that .NET is creating by using the power of strong typing and providing facilities towards gradual introduction of dynamic typing. This will hopefully allow for existing functionality that applies to strongly typed objects to be used against dynamically typed objects.

As .NET grows so do the number of ways of tackling the same or similar problems. Event Handling is no exception.

//1

button1.Click += new RoutedEventHandler(button1_Click);

//2

button1.Click += button1_Click;

//3

button1.Click += delegate(System.Object o, RoutedEventArgs e)

                     {

                         System.Windows.MessageBox.Show("Click!");

                     };

//4

button1.Click += delegate

{

    MessageBox.Show("Click!");

};

//5

button1.Click += (o, e) => MessageBox.Show("Click!");

 

Personally I use approach 2 and 5 depending on the situation. Approaches 3, 4 & 5 are anonymous handlers which means that their name is determined at creation (so we don’t know what it is). This can sometimes be an issue if you want to unsubscribe from an event, see here. Again with this post Resharper will make suggestions to use approach 2 and 5.

I feel there is an important difference between approach 1 and 2 that should be elaborated on. Approach 1 delcares the delegate of RoutedEventHandler twice because the delegate is already specified in, and hence inferred from, the event declaration. This is shown below:

internal event RoutedEventHandler Click;

 

Inferring types rather than having duplicate definitions is important as it means that you don’t have to repeat yourself and when you refactor your code you will have an easier job updating it when it is specified once.

For those unfamiliar with delegates, delegates are method parameter contracts which in the case of RoutedEventHandler specifies that an implementer of its contract will have the parameters of (Object, RoutedEventArgs).

On the last line of code in the following code listing you will notice that the method of IList<T>.Add(T item) is called but with no parameter.

//our resulting output

IList<Person> lecturersEnrolledForStudy = new List<Person>();

//students and lecturers can enrol for study.

var newStudentEnrolementList = new List<Person>();

//filter the students out

var lecturersEnrollingInAClass = newStudentEnrolementList

                                    .Where(person => person.isLecturer)

                                    .ToList();

//add lecturers that are enrolling to the enrolled list.

lecturersEnrollingInAClass.ForEach(lecturersEnrolledForStudy.Add);

 

The parameter is still being populated like as if the following code was written:

lecturersEnrollingInAClass

            .ForEach(item => lecturersEnrolledForStudy.Add(item));

 

The parameter is inferred by the compiler just as the type of the “item” variable is by the lambda expression/list type. For those of us who are being weaned off traditional loops for these sorts of list interactions might find that it is more natural to think of the list that we are adding too first, and the list that the information is coming from second. This has reversed with lambdas.

A point worth making is that while this example I have provided is simple and could be done using an AddRange method, it is not as extensible and hence I suggest not using it. An example of the .ForEach extention methods extensibility would be that it can ‘addrange’s across different types and at different depths of objects. An example of this could be:

lecturersEnrollingInAClass

            .ForEach(item => lecturesNamesList.Add(item.Name));

In conclusion this is a handy shorthand to use with lambdas. If you already use the Resharper plug-in, this shorthand will have been suggested to you.

When first utilizing the new query techniques of .NET 3.5 such as LINQ and Lambda expressions I would always choose LINQ over lambda expressions. This was for two reasons:

1. LINQ looked more natural

2. Lambda expressions or the LINQ extension methods to be more accurate are often hidden away because either you are not using the correct type to access them, or don’t have the System.LINQ library in the using section.

As time has progressed I have realised that I now use lambda expressions almost exclusively. I feel that looking deeper into LINQ has facilitated this, specifically understanding the typing behind LINQ. Ultimately it comes down to preference as the compiler changes LINQ to use extension methods, see: here

An example of the difference in sytnax is:

var d = (from mp in MyProducts

         where mp.Price < 50d

         select mp);

 

var f = MyProducts.Where(mp => mp.Price < 50d)

 

I think that when your queries are smaller, that lambda expressions are quicker to write and more natural to the rest of C#. When a query becomes very large LINQ could be more concise but I haven’t yet come across such a situation. Also I am not a fan of single huge queries as it is an inconvenience for other developers if they need to modify a query. Its bigger, so takes longer to read, and multiple smaller queries means that code be executed in between queries. With PLINQ however there could be an advantage in have a single larger query, however I am not taking PLINQ into consideration today.