WinRT/C#: DataPackage and custom objects

Ok, after some intensive implementation weeks, I think I should blog some articles about tips’n’tricks when developing Windows 8 Metro apps with WinRT and C#. This first article is about the DataPackage class. You need to get in touch with this class when you want to exchange data from app to app by implementing the Share contract or when you want to implement custom drag&drop functionality in your own app. DataPackage has built-in functionality for exchanging a variety of document formats: Bitmap, Html, Rtf, Text, Uri and StorageItems (files and folders).

Especially in the drag&drop scenario these standard data formats often aren’t enough. Imagine a grouped ListView or GridView. Because of the grouping you have to implement drag&drop manually in WinRT Metro apps. Now if you want to exchange data between the drag event and the drop event, you often want to fill the DataPackage with data objects of your custom data types. Unfortunately, that’s not possible out of the box with the DataPackage. Only scalar types, implementations of IRandomAccessStream or IStorageItem and IUri are supported.

So, there’s no possibility to write the real instances of your objects into a data package in the drag event and read them in the drop event. But here’s the solution: serialization and writing into an IRandomAccessStream. While you serialize and deserialize your object, you won’t get the original instance in the drop event, but if it’s ok for you, then this method works fine.

I’ve written some extensions for DataPackage and IRandomAccessStream, that you can use to get this task really quickly done:

public static class IRandomAccessStreamExtensions
{
    public static async void WriteObject<T>(this IRandomAccessStream stream, T obj)
    {
        var serializer = new DataContractSerializer(typeof(T));
        serializer.WriteObject(stream.AsStreamForWrite(), obj);
    }

    public static T ReadObject<T>(this IRandomAccessStream stream)
    {
        var serializer = new DataContractSerializer(typeof(T));
        return (T)serializer.ReadObject(stream.GetInputStreamAt(0).AsStreamForRead());
    }
}

public static class DataPackageExtensions
{
    public static void SetObject<T>(this DataPackage data, string formatId, T obj)
    {
        var randomAccessStream = new InMemoryRandomAccessStream();
        randomAccessStream.WriteObject(obj);
        data.SetData(formatId, randomAccessStream);
    }

    public static async Task<T> GetObjectAsync<T>(this DataPackage data, string formatId)
    {
        var randomAccessStream = await data.GetView().GetDataAsync(formatId) as IRandomAccessStream;
        if ((randomAccessStream == null) || (randomAccessStream.Size == 0) || !randomAccessStream.CanRead)
        {
            return default(T);
        }

        return randomAccessStream.ReadObject<T>();
    }
}

Now you’re able to use the SetObject() and GetObjectAsync() extension methods on DataPackage to easily store and retrieve items to/from a data package in the drag/drop event or in your source/target implementation of the Share contract:

private void OnGridViewDragItemsStarting(object sender, DragItemsStartingEventArgs e)
{
    e.Data.SetObject("MyDataTypeList", e.Items.OfType<MyDataType>().ToList());
}

private async void OnGridViewDrop(object sender, DragEventArgs e)
{
    var myDataItems = await e.Data.GetObjectAsync<List<MyDataType>>("MyDataTypeList");
}

The string parameter „formatId“ specifies the identifier for your data format in the DataPackage. Note how the IRandomAccessStreamExtensions methods use the DataContractSerializer for serialization and deserialization. This means that your data class has to be decorated with the DataContract and DataMember attributes to specify which data should be serialized.

I hope you can use this little helper in some cases when working with the DataPackage for sharing data. In some next blog post I want to show you how to manually implement drag&drop in your grouped ListView and GridView in WinRT Metro apps. Stay tuned!

kick it on DotNetKicks.com

C#: Efficient retrieval of Expression values

Some days ago I’ve had an interesting technical discussion with a colleague of mine regarding the possibility of implementing Guard classes with Expressions in C#. Such a class enables easy argument checking in form of (technical) preconditions on method entry. Thereby the checking logic is encapsulated in the Guard class.

One method of such a Guard class could be AssertNotNull() which checks, if a given method argument equals null and if true throws an ArgumentNullException. By the use of Expressions the parameter to check can be given to AssertNotNull() in a very elegant way:

public void MyMethod(SomeType elem)
{
    Guard.AssertNotNull(() => elem);

    // actual method logic
}

Through evaluation of the Expression the AssertNotNull() method is able to extract both the name and value of the argument. Thus there’s no necessity to provide both as parameters to AssertNotNull(). Moreover you do not need to provide the argument name as string.

Value by compilation

It’s very easy to extract the argument value through compilation and invocation of the Expression. Hence this solution is often taken by developers who work with Expressions in this way. The following snippet shows this implementation:

public static class Guard
{
    public static void AssertNotNull<T>(Expression<Func<T>> selector)
    {
        T value = selector.Compile().Invoke();
        if (value == null)
        {
            string name = ((MemberExpression)selector.Body).Member.Name;
            throw new ArgumentNullException(name);
        }
    }
}

Value by evaluation

In the conversation with my colleague we caught the point that the extraction of the argument value from an Expression is even possible without performing the costly compilation. This is enabled by converting the Expression into a ConstantExpression, from which we can catch the value by executing GetValue() on a FieldInfo instance:

public static class Guard
{
    public static void AssertNotNull<T>(Expression<Func<T>> selector)
    {
        var memberSelector = (MemberExpression)selector.Body;
        var constantSelector = (ConstantExpression)memberSelector.Expression;
        object value = ((FieldInfo)memberSelector.Member)
            .GetValue(constantSelector.Value);

        if (value == null)
        {
            string name = ((MemberExpression)selector.Body).Member.Name;
            throw new ArgumentNullException(name);
        }
    }
}

This doesn’t look very spectacular on first sight. The code is more complicated and it’s necessary to provide a variable in the Expression. Properties and data hierarchies don’t work with this solution, but this shouldn’t be a problem when checking argument values against null. Of course with a more sophisticated solution (iterative/recursive evaluation of the Expression tree) you can enable such scenarios, but this is out of scope of this blog post…

Looking at the execution times

So what’s the point of the second solution? It’s simple: compilation is much more time-intensive! In a little runtime test I’ve compared both solutions. A call of AssertNotNull() with a valid argument (!= null) over 10.000 iterations resulted in the following execution times:

Please note the immensive time difference! The compiled solution takes more than 53 seconds, while the evaluation takes less than 0,35 seconds. This makes a time factor of more than 156, by which the evaluated solution is faster than the compiled approach.

Conclusion

When handling with Expressions you should take the execution time into account! Once a method is executed inside of a loop and you follow defensive programming and check method parameters at every place, an argument check can become an important time factor. When possible you should favor evaluation over compilation of Expressions.

kick it on DotNetKicks.com

Getting encapsulated type of Nullable

Just a short tip for today..

Sometimes I’ve had the requirement to treat value types, where I don’t know if the value type is Nullable<T> or not. Regardless of whether the value type is declared as Nullable<T> or not, it should everytime be treat as T. Thus I’ve had to find out the underlying type of the Nullable<T>.

The following extension method on Type realizes this requirement:

public static class TypeExtensions
{
    public static Type GetBareType(this Type dataType)
    {
        if (dataType != null)
        {
            if (dataType.IsGenericType &&
               (dataType.GetGenericTypeDefinition() == typeof(Nullable<>)))
            {
                dataType = Nullable.GetUnderlyingType(dataType);
            }
        }
        return dataType;
    }
}

Is the Specification Pattern obsolete?

I’m a guy who loves many of the new patterns that I get to know. But sometimes when I show that pattern to colleagues around me, they tilt their heads and say: „Arrrm, who needs this?“. Often they help me to get back to the ground and think again about intents and benefits of one or the other pattern.

Currently I’m rethinking the Specification Pattern, which has been introduced by Eric Evans and Martin Fowler some time ago and got some attention in the DDD community and beyond. The intent of the Specification Pattern is to separate the logic for (e.g.) filtering an entity from the entity itself. This responsibility is encapsulated in single classes – the specifications. Those specifications are given for example to a single method Filter() on a repository, which takes care of filtering the domain model by the specifications. Thus, you bypass the need for having several special methods in your repository which take care of the actual filter operation (such as FilterByCustomerName(), FilterByCustomerAddress() etc.).

An example interface snippet for a repository of persons with a specification filter method could then be:

interface IPersonRepository
{
    IEnumerable<Person> Filter(ISpecification<Person> filterTerm);
    // ...
}

Summarized, some key benefits of the Specification Pattern are:

  • Loose coupling of the filter logic from the objects being filtered,
  • Single responsibility: Interface of repository/data provider isn’t polluted with lots of filter methods,
  • Callers can express in a flexible way by which criteria entities can be filtered,
  • Composition of specifications (e.g. by a fluent interface) yields to flexible filter queries, for example:
    [sourcecode language=’c#‘]var filter = Filter.By(25).And(„Frankfurt“)[/sourcecode]

But now the provocative question that one could come with: Who needs the Specification Pattern in times of C# 3.0 and Expressions? This might sound disturbing at first, but let me explain…
C# 3.0 came up with the new concept of Expressions/Expression trees. This way, code can be treated as a kind of syntax tree in the program. Developers can extend the tree with additional code portions and then compile it into executable code which can be invoked.

Therefore Expressions seem to give us similar benefits for filtering as specifications do. By using Expressions, we are able to define a single Filter() method on the repository, which gets an appropriate Expression as argument. Consumers of the repository can call this method with their custom filter Expressions and thus we’ve got the same benefits: loose coupling of filter logic and objects to be filtered, flexibility for callers to provide custom filter criteria and the possibility to combine several filter criteria (several Expressions).
One could argue that with specifications we’ve got better encapsulation of the filter logic into separate classes. But this can be done with Expressions as well (e.g. by separate wrapper classes or dedicated Expression providers), so that isn’t a good argument…

The interface of a repository of persons with a filter that uses Expressions might look like this:

interface IPersonRepository
{
    IEnumerable<Person> Filter(Expression<Predicate<Person>> filterTerm);
    // ...
}

This leads again to the question: Do we still need the Specification Pattern or is it already embedded with Expressions in the language (C# 3.0) itself?

Pattern focus

First I want to mention that the intent of a pattern is not (only) to provide a technical solution, but also a conceptual guideline for a problem at hand. Thus Expressions as technical solution don’t cover the intent of the Specification Pattern. The Specification Pattern can be implemented with the help of Expressions, but that’s another point. So, directly comparing the Specification Pattern with Expressions is like an apple-pear-comparison.

Encapsulation focus

Let’s come to use cases when I would prefer the use of dedicated specification classes rather than directly using Expressions.
First as a team lead you could want to enforce the use of dedicated specification classes in your development team (thus enforce encapsulation of the filter logic). By giving Expressions or Predicates to filter methods directly,  developers would be allowed to define filter expressions whereever they want to. You don’t have the control over this process and please don’t trust your project guidelines: If developers are allowed to do something wrong, they will do.

With specifications you can force your team members to write specification classes for their requirements, which leads to enforced encapsulation. Furthermore you drive reuse of existing specification classes. Other developers are encouraged to use existing specifications, especially because of the additional effort for writing new specifications. By combining several specifications, the reusability aspect is pushed even more.

Domain model focus

Giving consumers the full flexibility of defining custom filter criteria with specifications can be very handsome in many situations. However, in other scenarios instead of giving full flexibility, you may want to restrict the set of filters for your domain model. If you focus on your domain, you perhaps want a restricted set of specifications, each with a very specific meaning in your domain! Binding such specifications to your domain model makes the purpose of your domain and how it can/should be used in terms of filtering much clearer.

Technically, in order to restrict access to a particular set of specifications, you could create sealed specification classes inside of your domain model services (same layer as repository). Consumers of the repository would be allowed to call the Filter() method on the repository with those specifications (and compositions of those), but they would not be able to create new specifications if you don’t mark the specification interface as public. This way you get two characteristics: Restricted filtering, which fits into your domain and your use cases on the one hand, and encapsulation/separation of filter logic and entities which should be filtered on the other hand.

Bottom line

This article started with an interesting and provocative question: Is the Specification Pattern obsolete? This question came up with a look at Expressions in C# 3.0. Technically you can achieve similar results when using Expressions instead of implementing the Specification classes by hand. But as the last sections have shown, in my opinion the Specification Pattern is not obsolete! As pattern it’s adding very specific value to the plain technical solution, when you take encapsulation and domains into account. Then it clearly goes beyond the technical aspect which many developers see at first sight.

Those are my current thoughts on specifications, but of course my opinions are not carved in stone. What do you think? What points I’ve missed perhaps? I’m eager for your comments!

kick it on DotNetKicks.com

C# covariance and contravariance

Hey guys. Sorry that I was not posting bigger stuff for a long time. I’ve had some personal time-eaters during the last months, but I hope it will get better soon. Today’s topic during this article is covariance and contravariance in general and especially in C#. What is it? Who needs it? How is it supported today? How will it be supported in C# 4.0? Answers have to be found…

So, covariance and contravariance are features of a programming language’s type system (not limited to C# at all). More precisely (and theoretically), they are characteristics of binary operators, which convert one type to another type. Generally if an operator changes the type in some kind, it’s called variant. If it retains the type (the type is fix), then it’s called invariant. Two types of variant operators are contravariant and covariant operators. In fact, there are other types of variance (consider dynamic typing, duck typing etc.), thus covariant/contravariant operators are just two examples for that. If an operator orders types in the way from general to more specific for any type, then it is called to be covariant. If it orders types reversely from specific to more general, then it’s contravariant.

So far the theoretical introduction. It’s pretty much saying nothing about what both terms mean in your practical coding life, isn’t it? Well… in programming languages there are two features where co- and contravariance can make sense: return type covariance and parameter type contravariance.

Return type covariance

Let’s consider the interface IClonable for a moment. It’s declared as:

public interface ICloneable
{
    object Clone();
}

If we want a class Foo to implement this interface, then it has to apply the exact same signature:

public class Foo : ICloneable
{
    public object Clone()
    {
        Foo clone = new Foo();
        // cloning implementation
        // ...

        return clone;
    }
}

Wouldn’t it be nice to have a method public Foo Clone() instead? That’s what return type covariance means. With this, the return type would be narrowed by more specific implementations or derivations. It would give type-safety to all callers of the method. Yes, this would be nice, indeed. But that’s a feature, which is currently not implemented in the C# language. The more general return type in the interface or a base class can not be narrowed on implementing or deriving classes. The same problem arises in a number of cases and on generics, as we will see later on.

Parameter type contravariance

If we got a method on an interface or base class which takes a parameter X, then contravariance is all about wanting a more general parameter in the implementation method of that interface or in a derived class. C# doesn’t support that, yet. For example, the following will not work:

class Fruit { }
class Apple : Fruit { }
class Cherry : Fruit { }
class FlavorComparer : IComparer<Fruit> { ... }

public void SortApples()
{
    List<Apple> apples = GetSomeApples();
    IComparer<Fruit> flavorComparer = new FlavorComparer();
    apples.Sort(flavorComparer);
}

FlavorComparer compares two fruits based on their flavor. Apples are fruits, so why shouldn’t they be sorted with use of the FlavorComparer? This would be nice, but Sort() needs a IComparer<Apple> and not the more general argument IComparer<Fruit>. It should be no problem for using the more general comparer, but C# doesn’t support this at the moment.

Covariance on arrays

Since the first C# (1.0), covariance on arrays is supported. Thus, one could write:

Fruit[] fruits = new Apple[10];
fruits[0] = new Cherry();

An array of a reference type can be viewed as an array of its base type or any implemented interface. That’s no problem for the compiler, it just works. But at runtime, that example would produce an ArrayTypeMismatchException and that’s what one would expect in this example. Creating apples and setting one to a cherry is no good idea.

Well, but why does it compile? That’s a historical problem. In the first version of C#, it has been designed to attract as many developers as possible and since this type of covariance worked in Java, the C# guys applied it to their language as well. Not that good idea, but that’s another story…

Covariance and contravariance on generics

Generics in C# 1.0 to 3.0 are invariant (fix). If we map the array example to generics, then the following code will not work:

List<Fruit> fruits = new List<Apple>();
fruits.Add(new Cherry());

In this case, there’s no exception thrown at runtime, but already the compiler comes up with an error message at the first line. Invariance on generics is a serious limitation of current C# versions, since it doesn’t allow many intuitively correct cases.

For example, if you have a method List<Fruit> GetFruits() on the Fruit class, which gets overridden by the Apple class, then you can’t return an instance of List<Apple>, which should be no problem intuitively. The following code on Apple is not working:

public List<Fruit> GetFruits()
{
    List<Apple> fruits = GetApples();
    return fruits;
}

The same problem arises, if we want to have a list of fruits, which should be a Union of apples and cherries, which are both fruits…

List<Fruit> fruits = new List<Fruit>();
List<Cherry> cherries = GetCherries();
List<Apple> apples = GetApples();

fruits = fruits.Union(cherries).Union(apples);

This or similar code doesn’t work as well.

C# 4.0

Having all that in mind, C# 1.0-3.0 is some kind of nerving limited in terms of covariance and contravariance. It has covariance on arrays of reference types and C# 2.0 introduced covariance and contravariance on delegates (which obviates some really annoying workarounds), but at the whole there should be better language support of those type-system features.

But a knight in shining armour is approaching: C# 4.0 arises on the horizon! But does it hold what it looks like? In fact, with C# 4.0 you have the in and out keywords, which you can define on type arguments of interfaces and delegates.

With the out keyword you can define a type parameter to be covariant. This means, that implementations of methods which return an object of this type can also return a more specific type. The standard example in this case is IEnumerable<out T>:

public interface IEnumerable<out T> : IEnumerable
{
    IEnumerator<T> GetEnumerator();
}

public interface IEnumerator<out T> : IDisposable, IEnumerator
{
    T Current { get; }
}

This allows you to write e.g.:

IEnumerable<object> list = new List<string>();

and

IEnumerable<Fruit> fruits = new List<Apple>();

It allows you to have a base type as type parameter of an IEnumerable instance and a more specific type if you assign something to it. But wait: there’s a limitation on that… out T means: no method in this interface is allowed to use T as parameter! The word „out“ makes this clear and it limits the use of those covariance to just a few interfaces. For example, this cannot be set on the ICollection<T> interface (and furthermore on IList<T>, because of IList<T> : ICollection<T>). ICollection<T> includes a method Add(T item) and since no T is allowed to be used when out T is declared, that wouldn’t work. Now, most of my own generic interfaces and many .NET interfaces as well use type parameters as in- and output, so this new type of covariance seems to be not this influencing. For example, the following code would not work:

IList<object> list = new List<string>();

But why? There’s an important aspect on that and that is the same as on the array example in the paragraph „Covariance on arrays“. Having the Add() method, one could add an instance of type object to the list and that has not to be allowed:

IList<object> list = new List<string>();
list.Add(new object());  // mustn't be allowed

Sure, that’s a big limitation, but it makes sense and is absolutely necessary!

The same comes true for the in keyword. One can define an interface with type parameter in T. With that, T can only be used as type parameter and not as return value. But this brings contravariance on the type parameters to life. Having the FlavorComparer example from above in mind? That will work, if IComparer<in T> is declared by the .NET framework. The limitation of T to be set as method parameter only is necessary due to the same aspect as for the out keyword. If IList<in T> should have been declared and one defines a variable IList<string> list and calls list.Add(new object()), then it would make no sense to iterate through all list elements as string, because the inserted object is no string and would cause problems.

So in the end, the knight’s armour is not that shiny. C# 4.0 comes with some nice covariance and contravariance features, but the out and in parameters are fairly limited (and using them together is (luckily) not allowed). Many people are annoyed about that, but I don’t share their opinion. It’s a good thing to have covariance and contravariance on type parameters separated from each other! Else this would produce heavy problems as we have seen in the examples above and in the array covariance section. My opinion is, that the language designers have done a good job here. I don’t want to have some kind of ArrayTypeMismatchException on generics and thus in/out on type parameters are a good thing.

Links:

kick it on DotNetKicks.com

C# 4.0 Neuerungen

Die ersten Neuerungen kurz in 3 Stichpunkten:

  • Aufruf dynamischer Sprachen: dynamic-Schlüsselwort
  • Optionale Funktionsparameter wie in C++ (wie ich das vermisst habe!)
  • Rückgabe anonymer Typen durch Funktionen

Einen umfassenden Überblick über die Neuerungen gibt ein Word-Dokument, welches Microsoft hier zum Download bereitstellt.

Links:

Die Zukunft von C#

Da ich stets in aktuellen Entwicklungen von C# interessiert bin, habe ich ein wenig im Internet recherchiert und fasse nachfolgend einige interessante Hinweise mit den entsprechenden Links zusammen, wo die Reise hin geht. In Zukunft möchte ich diesen Text mit aktuellen Entwicklungen weiter ausbauen, die derzeitige Version ist lediglich als Ausgangspunkt gedacht.
 
Integration von C-Omega Sprachelementen
 
C-Omega ist eine experimentelle Sprache von Microsoft Research und offiziell gibt es keine Pläne für deren Verwendung. Trotzdem fand bereits die Übernahme einiger Sprachelemente in C# statt, wie es auch in einem Interview mit Anders Hejlsberg zur Sprache kommt. Bei C-Omega handelt es sich um eine Spracherweiterung von C#. Sie fokussiert dabei vor allem auf Probleme, welche bei der Erstellung netzwerkartiger, lose gebundener Applikationen entstehen. Diese betreffen die nebenläufige/parallele Programmierung auf der einen Seite und die Integration von relationalen Daten und XML auf der anderen Seite.
 
Beim Thema Nebenläufigkeit werden einige Konzepte eingeführt, die zunächst unter dem Namen „Polyphonic C#“ implementiert wurden und auf die bessere Unterstützung paralleler Abarbeitung (zum Beispiel durch neue Sprachelemente und die bessere Unterstützung von Asynchronität) abzielen. Mit einer besseren Einbindung relationaler Daten sollen weiterhin die bisher nahezu getrennten Welten der Programmiersprachen und der Datenbanken miteinander vereint werden, indem ein leichterer Datenzugriff aus der Programmiersprache heraus stattfindet und dabei für Typsicherheit gesorgt wird. C-Omega setzt diese Idee um mit LINQ wurde dieses Konzept in .NET übernommen. Auch der getypte Zugriff auf XML-Daten bzw. die einfache und typsichere Traversierung eines XML-Baums ist in C-Omega möglich, allerdings fand noch keine direkte Übernahme in C#/.NET statt (abgesehen von der LINQ-Unterstützung für XML-Daten). Hier darf man gespannt sein, ob und wann dies nachgeholt wird.
 
Nebenläufige/Parallele Programmierung
 
In der besseren Unterstützung nebenläufiger Programmierung bzw. der Erstellung paralleler Programme liegt eine große Herausforderung für die weitere Programmiersprachenentwicklung, bei der C# durch seine derzeit noch vorherrschende hohe Dynamik eine Vorreiterrolle spielen kann. Dem Thema Parallelität kommt dabei eine wachsende Bedeutung zu, da sich die Architektur heutiger Rechner und Netzwerke durch die Verbreitung von Multicore-Ansätzen und der lose gekoppelter Netzwerke (Cloud Computing) stetig wandelt. Jedoch wird Parallelität auch von aktuellen Programmiersprachen wie C# oder Java nur über Thread-und-Lock-Ansätze unterstützt, welche in den 1970er Jahren entwickelt wurden und die Programmierung nebenläufiger Applikationen schwer und unhandlich machen.
 
Microsoft hat mit dem Parallel Computing Developer Center einen Bereich geschaffen, der sich dem Thema Parallelität/Nebenläufigkeit widmet und dem einige Hinweise auf Entwicklungen für C#/.NET entnommen werden können. So sind mit den Parallel Extensions eine ganze Reihe von Spracherweiterungen für C#/.NET verfügbar, welche erste Möglichkeiten für die einfache Erstellung paralleler Programme beinhalten. Neben thread-sicheren Collections bietet z.B. die Klasse System.Threading.Parallel statische Methoden „For“, „ForEach“ etc. an, mit denen eine einfache Parallelisierung von Programmkonstrukten erreicht werden kann. Interessant ist ebenfalls die Einbindung eines parallelen LINQ (PLINQ).
 
Zukünftig dürfte es nicht bei einer Spracherweiterung bleiben. Die Parallel Extensions werden meiner Meinung nach bald in neue Releases von C# bzw. das .NET-Framework selbst Einzug halten und so die parallele Programmierung vereinfachen. Doch das dürfte erst die Spitze des Eisberges sein. Mittelfristig ist ein kompletter Paradigmenwechsel zur parallelen Programmierung hin nötig, was allein über Spracherweiterungen schwer erreichbar erscheint. Auf jeden Fall sind neue Sprachkonzepte erforderlich, welche die Übersichtlichkeit bei der Erstellung großer paralleler Applikationen wahren und wiederkehrende Muster in eigene Konstrukte kapseln. Eine Art Katalog an „Parallel Design Patterns“ wäre hierbei sicherlich hilfreich.
 
Was Microsoft zu dem Thema zu sagen hat, wird auf der PDC 2008 öffentlich werden. Mit einem separaten Pre-Conference-Day und 4 Konferenz-Sessions auf der PDC wird der Parallelisierung genügend Raum geboten.
 
C# 4
 
In einem Interview mit den C#-Designern auf Channel 9 werden erste Details geliefert, in welche Richtung sich C# 4 entwickeln könnte. Unter anderem wird über die Notwendigkeit von C# gesprochen, mit „dynamischen“ Sprachen wie IronPython oder IronRuby zu interagieren und diese besser einzubinden. In diesem Zusammenhang könnte es auch zu einem Ausbau der Möglichkeiten für das Meta-Programming kommen. In dem Interview wird ebenfalls eine Vereinfachung konkurrierender Aufrufe angekündigt.
Insgesamt stellt sich die Frage, wie weit die Sprachdefinition selbst mit neuen Features aufgebläht werden sollte, ohne sie zu unübersichtlich zu machen und Entwickler (vor allem Neueinsteiger) abzuschrecken.
 
Diese anderen Sharp’s…
 
Ein Blick auf Microsoft Research lohnt immer, da Forschungs-Projekte zunächst zwar losgelöst sind von konkreten Applikationen, jedoch Microsoft auch einen Nutzen bringen sollen und damit früher oder später Auswirkungen auf bestehende Elemente wie C# und .NET haben.
 
Spec# stellt beispielsweise eine Spracherweiterung für C# dar, welche die Erstellung von Qualitätssoftware vereinfachen soll. Das grundlegende Prinzip ist dabei programming by contract. Der Programmierer gibt vor, wie sich beispielsweise eine Methode zu verhalten hat (Vor- und Nachbedingungen), was in der Spec#-Syntax geschieht. Zur Compilezeit wird geprüft, ob die Methode diesen „Vertrag“ einhält. Programming by contract ist auch für die Parallelisierung von Programmen interessant, da hierüber ausgesagt werden kann, wie sich eine Funktion verhält, z.B. ob sie interne Zustände einer Klasse ändert oder andere Seiteneffekte hat. Der Compiler kann dann anhand dieser Aussagen und ihrer Prüfung entscheiden, wie eine Parallelisierung anzustreben ist.
 
Dass sich gewisse Dinge in einer funktionalen Programmiersprache einfacher und schneller implementieren lassen, ist hinlänglich bekannt. Quicksort lässt sich z.B. in Haskell elegant in 3 Zeilen Code abhandeln. F# stellt eine Implementierung des funktionalen Programmierparadigmas dar, auch wenn es nicht „rein“ funktional ist. Gewisse Konstrukte wie die Lambda-Ausdrücke wurden bereits in C# integriert, andere Anleihen dürften folgen. Auch anderen Paradigmen wie der deklarativen Programmierung sollten man ein Augenmerk schenken, hier wurde mit WPF/XAML ja auch schon ein erster Beitrag geleistet. Funktionale Programmierung ist für das Sprach-Design-Team bei Microsoft besonders interessant, da funktionale Programme per se frei sind von Seiteneffekten. Sie lassen sich daher von Haus aus gut parallelisieren. Es wird zwar kein kompletter Paradigmenwechsel angestrebt (dafür sind funktionale Programme zu ineffektiv), aber es werden „Inseln“ in der funktionalen Programmierung gesucht, mit welchen sich die aktuellen Probleme imperativer Programmiersprachen wie C# elegant handhaben lassen.
 
Weitere Links