MEF is a new library in .NET Framework 4 and Silverlight 4 that addresses the problem of easily extending and componentising applications by providing a nifty framework. Adding an easy ability to extend your application, whether it be for the purposes of componentising your application or allowing others to extend your application has always been available to Delphi users in the guise of frameworks like RemObjects Hydra, the TMS Plugin Framework or building your own homebrew solution but MEF is very nice framework.

MEF is incredibly powerful and I’ll only really be scratching the surface and introducing it here.

Imagine an application which runs a sequential series of processes on an imaginary input file, not exactly rocket science but this is only a basic introduction after all.

First I begin by defining an Interface in a separate assembly which all my plugins will adhere to:

  IFileAction = public interface
    method ProcessFile(path: String);
    property Name: String read;
    property Version: String read;
  end;

We then write our first plugin, which we’ll conveniently call the MyHelloPlugin. First create a new assembly and reference the base plugin assembly which contains our IFileAction interface and the System.ComponentModel.Composition assembly. We also need to ensure that we reference these in our uses clause of the unit containing our Hello Plugin class. The My Hello Plugin class looks like this:

  [Export(typeof(IFileAction))]
  MyHelloPlugin = public class(IFileAction)
  const
     MYNAME = 'The My Hello Plugin';
     MYVERSION = '1.0.1';
  public
    method ProcessFile(path: String);
    property Name: String read MYNAME;
    property Version: String read MYVERSION;
  end;

This should be pretty self explanatory but we have two properties for our name and version and a ProcessFile method which will be called by our host app, providing it with a path for the file that we’re processing. You’ll notice the Export attribute which denotes what we’re exporting. We’re specifying the type of the export but in many cases you may not even need to do this. MEF has a very powerful ExportMetaData system for providing information about what you’re exporting which is also worth reading up on.

Next, of course, we need to actually consume the plugins in our main application. To manage my collection of plugins, I’ll create a small, basic class to hold and manage them:

  PluginList = class
  public
    [ImportMany(typeof(IFileAction))]
    property FileActions: IList<IFileAction> read write;
    constructor;
  end;

Here I’m using the ImportMany attribute to indicate that I’m expecting to import many IFileAction instances and then providing a list with which to populate (which, as always, you must remember to instantiate before you attempt to fill it!).

Next I’ll load up my Hosting catalog and compose the parts of my application.

  var aggregateCat := new AggregateCatalog();
  // var catalog := new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly());
  // var catalog := new AssemblyCatalog('plugins\MyHelloPlugin.dll');
  var dirCatalog := new DirectoryCatalog('plugins');

  // Add our Catalogs here,
  aggregateCat.Catalogs.Add(dirCatalog);

  var container := new CompositionContainer(aggregateCat);
  // Create our plugin hosting object
  var pluginList := new PluginList();
  // Compose the parts.
  container.ComposeParts(pluginList);

You’ll note that I create an AggregateCatalog which isn’t strictly necessary in this case because I’m only adding one ComposablePartCatalog to it but in other uses this would also allow me to separately load single Assemblies or a collection of DirectoryCatalog’s. I then load the catalog into a composition container before creating my aforementioned PluginList class and finally pulling all the parts together. It really is that simple. You can test what has been loaded using our now populated PluginList.FileActions collection, like this:

  for each plugin: IFileAction in pluginList.FileActions do
  begin
    Console.WriteLine('Loaded ' + plugin.Name + ', version ' + plugin.Version);
  end;

You can now create a new and entirely different plugin assembly (or many, many more) and providing it conforms to our IFileAction interface and is either in our target directory or loaded manually, it will now appear in our list as if by magic.

Once you’ve begun using MEF, you’ll find out how powerful it can be and how easy it makes building modular applications.

If anyone is interested in me uploading the complete project set for this sample then please let me know in the comments below and I can upload it to github. If anyone else has any excellent samples of MEF usage that they can publish we could even start a sample repository.

Further Reading

• The MEF Architecture Overview
• The MEF Programming Guide
• The MSDN System.ComponentModel.Composition Guide

Visual Studio 2010 Support

I’ll start with the most obvious change: Delphi Prism now supports Visual Studio 2010 which was only released just over a month ago. The Visual Studio 2010 IDE looks great, feels faster than 2008 and most importantly, in my experience, is very stable.

Visual Studio 2010 with Delphi Prism

The shell is based on WPF and has had considerable work put into allowing it to be flexible and extensible which I understand has allowed a whole host of new plugins to flourish. It’s an extremely minor point but I’ve also found it much better in allowing themes for the code editor, springing forth sites like http://studiostyles.info/. My favourite scheme  is Son of Obsidian which works marvellously for C# code and works reasonably well for Delphi Prism code too. It’s great that we can take advantage of community extras like this, although it would also be great if we could tailor some of these themes specifically for Delphi Prism.

As marc mentioned back on episode #39 of the Podcast at Delphi there are a lot of free minor improvements that come with moving to Visual Studio 2010 (not financially free but that were inherent with the migration).

Other cool stuff includes support for Silverlight 4 and the “Paste C# as Oxygene” feature which allows you to translate code snippets on the fly. This release also includes MonoDevelop which includes support for Mac and Windows.

For, If and Case Expressions

For, if and case I hear you say? Haven’t we had those for as long as we can remember? Not like this we haven’t. Delphi Prism now supports them as expressions. This allows you to do operations like this:

  var sourceList: Array of Integer := [1 ,2 ,4 ,8 ,16 ,32 ,64 ,128];
  var sqList := for each num in sourceList yield num * num;

Now this sample could just as easily be done with a LINQ operation or a separate loop but this is another option available at your disposal and introduces a slightly Functional Programming feel. Delphi Prism now also supports If expressions and my favourite expression addition: case.

These expressions, as with so many language features hold the potential for misuse but they can also make things a little more concise:

method NotifierStr(newMails: integer): string;
begin
  result := 'You have ' + newMails.ToString() + ' new ' +
    case newMails of
      0: 'emails';
      1: 'email';
    else
      'emails';
    end;
end;

Please forgive the horrible string concatenation but I wanted to demonstrate it in this way because I thought it might help make it a little clearer.

Dynamic

Delphi Prism 2011 includes support for the (in some cases) contraversial .NET 4 dynamic type. To quote Scott Hanselman on dynamics: A dynamic is a statically typed dynamic type. Dynamics leave a lot more till run-time and allow a much cleaner interop with the Dynamic Scripting languages built upon the CLR.

For example, the ExpandoObject enables you to add and delete members at runtime, something might be useful when serialising and deserialising JSON or XML where you do not know the spec ahead of time:

dynamic tweetresult := new ExpandoObject();
tweetresult.Id = 1243535345;
tweetresult.Username = 'delphifeeds';

The Delphi Prism 2011 implementation has a required dependency upon a separate assembly, RemObjects.Oxygene.Dynamic.dll, which is freely re-distributable.

For a much better idea of what dynamics are and can be used for, I would refer you to Scott Hanselman’s whirlwind tour of dynamics and the MSDN reference on using dynamics.

Tail Calls

Tail Calls are another feature that could be seen as similar to a Functional Programming Language construct. They are essentially an exit statement followed by a call to a method. They have to be explicitly enabled and disabled for a method using the {$TAILCALL ON} flag. This allows you to code recursive functions, particularly useful for maths based methods. This concept will probably take a bit of getting used to and are something I’d like to cover in subsequent posts.

Tuples

A Tuple is an ordered list of Elements. They can contain 1 to 7 different references and types with an 8th reference being used to reference another Tuple if you need to hold more than 7. They are similar to an array and a class/record but unlike an array can contain more than one type and require considerably less declaration than a class/record. A Tuple in Delphi Prism might be used as follows:

  var telephoneList := new Dictionary<Tuple<string, integer>, String>();
  telephoneList.Add(Tuple.Create('Josh Moore', 1283843), '+0014158343131');
  Console.WriteLine(telephoneList[Tuple.Create('Josh Moore', 1283843)]);

They are particularly useful for returning more than one value from a method where you would otherwise need to explicitly declare a class or record to hold the data otherwise. Tuples are a good way to solve a specific problem and will be more familiar to those who have used them in other languages such as the Tuple support in Python.

Parallel Loops (not actually a new feature)

Parallel loops have been a part of the Delphi Prism (and formerly Oxygene) language for a long, long time. However what I hadn’t appreciated was that the Parallel Task Library upon which it relied was officially bundled into the .NET 4.0 Framework libraries. As such I felt it necessary to re-raise it and show just how nifty it is here even though it isn’t really new to Delphi Prism 2011.

Just to recap, with the parallel keyword you can parallelise a loop.

As a fully fledged .NET 4 language we can also use the AsParallel() method in order to return a ParallelEnumerable source capable of being queried with the .NET Parallel LINQ library.

The rough and ready example below demonstrate these two techniques:

class method ConsoleApp.Main(args: array of string);
begin
  var anagramletters := 'mite';
  var filepath := 'mydictionary.txt';

  var dictList := new List<string>();
  dictList.AddRange(System.IO.File.ReadAllLines(filepath));
  Console.WriteLine('Added ' + dictList.Count + ' lines to the file');

  var sortedList := new Dictionary<string, string>();

  for parallel i: Integer := 0 to dictList.Count - 1 do
  begin
    sortedList[dictList.Item[i]] := dictList[i].Sort();
  end;

  var matchingwords := sortedList.AsParallel().Where(w -> ((w.Value.Length = anagramletters.Length) and (w.Value = anagramletters.Sort()))).Select(w -> w.Key);

  Console.WriteLine('Found: ' + matchingwords.Count().ToString() + ' results');
  matchingwords.ToList().ForEach(x -> Console.WriteLine(x));

  Console.ReadLine;

end;

The code above reads a dictionary file in and then builds an index using a parallel loop before finding the words that are anagrams of the provided string using a Parallel LINQ query.

Extension Methods

I consider it a slightly more minor point as I’ve already briefly talked about the new method of defining Extension Methods, but this is now baked into Delphi Prism 2011 and is a pretty useful tool to have. I used the new Extension Methods syntax in the Parallel Example above to add an implementation specific Sort() method to my strings like so:

interface

extension method String.Sort : String;

implementation

extension method String.Sort : String;
begin
  var c := self.ToCharArray();
  Array.Sort(c);
  result := new string(c);
end;

Summary

Overall Delphi Prism 2011 is a pretty significant release and contains lots of new features that represent a lot of interesting new potential both on the language side and the IDE side, congratulations to the RemObjects team.

Further Reading

• What’s new in Delphi Prism 2011 – The Official Embarcadero page.
• New Features – The Delphi Prism Documentation Wiki page listing newly added features.
• Delphi Prism 2011 Release Notes – Is what it says on the tin.
• Using Type dynamic in .NET 4.0 – MSDN reference on the dynamic type.
• What is tail-recusion – StackOverflow answer on Tail Recursion which might help you to better understand Tail Calls in Delphi Prism.

So what is the Rx Framework?

It’s a framework for asynchronous programming from Microsoft Research (including Erik Meijer & Wes Dyer amongst others) which could potentially be para-phrased as LINQ to Events. The basic problem is that Asynchronous programming is hard, the exacerbating issue for this problem is that it is entirely necessary for modern development. It is pretty common for Desktop applications to need to chain a series of events together with the correct order and sometimes correct time but doing so at present can land you in a spaghetti-like sea of event callbacks. Enter the Microsoft Rx Framework.

What do I need?

The Framework requires a minimum .NET Framework version of .NET 3.5 SP1 or .NET 4 but downloads for both versions are available on the Microsoft Research site. I couldn’t work out why but Delphi Prism appears to have a problem with the Libraries use of Extension Methods but this issue appears to be fixed in the latest Beta of Delphi Prism. I now suspect it might have started working as a result of the updated support for Extension methods which marc hoffman recently posted about.

How does it work?

In Brief: The Rx Framework introduces a of a pair of interfaces, the IObserver & IObservable, which allow you to represent push-based observable collections, along with a library of extension methods (the bit that wasn’t previously working in Delphi Prims) that implement the Standard LINQ Query Operators.

And…

I always find that the easiest way to understand it is to view some examples. First you’ll need to make sure reference the System.CoreEx and System.Reactive assemblies.

As with always, we’ll start with an entirely useless example just to demonstrate a basic example which uses an Observable Timespan interval to print out a number which doubles every 2 seconds:

class method ConsoleApp.Main(args: array of string);
begin
  var oneNumberPerSecond := Observable.Interval(TimeSpan.FromSeconds(2));

  var numbersTimesTwo := from n in oneNumberPerSecond
                        select n * 2;

  Console.WriteLine('Numbers * 2:');

  numbersTimesTwo.Subscribe(num -> begin Console.WriteLine(num) end);

  Console.ReadKey();
end;

Clearly, this is a contrived example but I think this hints at a few of the more powerful features and versatility of the Rx Framework. The first thing to note is that this is an Asynchronous process, imagine the same code using the standard .NET Timer class. This is a demonstration of the power of the Observable Interfaces and how it can allow standard interfaces to concepts that would otherwise complicate our code such time windows to be easily expressed. The second lines to notice is the highlighted LINQ To Events code on lines 5 and 6 which show how easily you can filter specific events from any events. This is a truly powerful and important concept because it is fairly common to generate a stream of events, only some of which we want to react to and the Linq extensions allow us to express this in a succinct way.

This is only a basic console application but it’s not hard to imagine how this could make the complex ordering and timing of GUI events in many applications much easier. As another example I have translated the C# ISubject ping pong example which mimics the classic Ping Pong Actor example that the Scala folks get so excited about.

First of all the Ping ISubject and Pong ISubject classes:

namespace PingPongExample;

interface

uses
  System.Collections.Generic,
  System.Linq,
  System.Text;

type
  Pong = public class (ISubject<Ping, Pong>)
  private
  protected
  public
    method OnError(exception: System.Exception);
    method OnCompleted;
    method Dispose;
    method Subscribe(observer: System.IObserver<PingPongExample.Pong>): System.IDisposable;
    method OnNext(value: PingPongExample.Ping);
  end;

implementation

method Pong.Dispose;
begin
  OnCompleted();
end;

method Pong.OnCompleted;
begin
  Console.WriteLine('Pong finished Ponging');
end;

method Pong.OnError(exception: System.Exception);
begin
  Console.WriteLine('Exception');
end;

method Pong.OnNext(value: PingPongExample.Ping);
begin
  Console.WriteLine('Pong received Ping..');
end;

method Pong.Subscribe(observer: System.IObserver<PingPongExample.Pong>): System.IDisposable;
begin
  result := Observable.Interval(TimeSpan.FromSeconds(2.5))
                .Where(n -> n < 10)
                .Select(n -> Self)
                .Subscribe(observer);
end;

end.

namespace PingPongExample;

interface

uses
  System.Collections.Generic,
  System.Linq,
  System.Text;

type
  Ping = public class (ISubject<Pong, Ping>)
  private
  protected
  public
    method OnNext(value: Pong);
    method OnError(error: Exception);
    method OnFinished;
    method Subscribe(observer: System.IObserver<PingPongExample.Ping>): System.IDisposable;
    method OnCompleted;
    method Dispose;
  end;

implementation

method Ping.OnNext(value: Pong);
begin
  Console.WriteLine('Ping received Pong..');
end;

method Ping.OnError(error: Exception);
begin
  Console.WriteLine('Exception');
end;

method Ping.OnFinished;
begin
  Console.WriteLine('Completed Ping Ponging');
end;

method Ping.Dispose;
begin
  OnFinished();
end;

method Ping.OnCompleted;
begin

end;

method Ping.Subscribe(observer: System.IObserver<PingPongExample.Ping>): System.IDisposable;
begin
  result := Observable.Interval(TimeSpan.FromSeconds(2))
                .Where(n -> n < 10)
                .Select(n -> Self)
                .Subscribe(observer);
end;

end.

And then our setup code:

class method ConsoleApp.Main(args: array of string);
begin
  var ping := new Ping();
  var pong := new Pong();

  Console.WriteLine('Any key to stop..');

  var pingSubscription := ping.Subscribe(pong);
  var pongSubscription := pong.Subscribe(ping);

  Console.ReadKey();

  pongSubscription.Dispose();
  pingSubscription.Dispose();

  Console.WriteLine('Ping Pong Completed..');
end;

You can embrace IObservable in your own business objects quite easily and begin pushing events throughout your application asynchronously:

type
  Invoice = class

  private
    paidDate: DateTime;
    paidSubject: Subject<Invoice>;
  public
    constructor;
    method MarkPaid(paidDate: DateTime);
    property Paid: IObservable<Invoice> read paidSubject.Hide();
  end;

  ConsoleApp = class
  public
    class method Main(args: array of string);
  end;

implementation

class method ConsoleApp.Main(args: array of string);
begin
  var myInvoice := new Invoice();
  myInvoice.Paid.Subscribe(n -> Console.WriteLine('Paid'));
  myInvoice.MarkPaid(DateTime.Now);
  Console.ReadLine();
end;

constructor Invoice;
begin
  Self.paidSubject := new Subject<Invoice>;
end;

method Invoice.MarkPaid(paidDate: DateTime);
begin
  Self.paidDate := paidDate;
  Self.paidSubject.OnNext(Self);
end;

It’s true that the examples above can be replicated quite easily without using the Rx Framework but within a short time of experimenting with the Rx Framework, I would hope that you should be able to see that it allows asynchronous event handling patterns to be expressed in a standard and more expressive manner.

I realise that this post is a little short on more practical examples but in my next post I’ll expand on some slightly more practical examples and some examples which demonstrate the Frameworks Power in handling GUI events in WPF Applications. It is also worth noting that the Rx Team recently released the RxJs framework which brings the Reactive Programming environment to Javascript.

Further Reading

For further information I would recommend:

• The Rx Wiki
• Wes Dyer’s introduction to the Rx Framework
• Wes Dyer and Erik Meijer from MS Research explaining the Rx Framework
• 101 Rx Samples (not quite 101 yet!)

Does the framework appeal to you? As always, if you have any thoughts or questions about using the Rx Framework with Delphi Prism then let me know in the comments below.

Last time, I had created an attribute which could only be attached to methods returning strings and used a home-made caching class, the Aspect looked like this:

namespace AOPCacheLibrary;

interface

uses
  RemObjects.Oxygene.Cirrus.*,
  RemObjects.Oxygene.Aspects;

type
   [AttributeUsage(AttributeTargets.Method)]
  MemCacheAttribute = public class(System.Attribute, IMethodImplementationDecorator)
  private
  public

    method HandleImplementation(Services: IServices; aMethod: IMethodDefinition);
  end;

implementation

method MemCacheAttribute.HandleImplementation(Services: IServices; aMethod: IMethodDefinition);
begin
  // Get a Reference to our Result Value
  var newResult := new ResultValue();

  // Get our MemCache Object
  var cacheType := Services.FindType('AOPCacheLibrary.MemCache');
  // Setup our static methods.
  var getDataProc := new ProcValue(new TypeValue(cacheType), 'getData', [new NamedLocalValue('cacheKey')]);

  // Assign the result of our cache request to a local variable.
  var getDataAssignment := new AssignmentStatement(new NamedLocalValue('strData'), getDataProc);

  // CACHE DATA USED: To assign our Cache'd data to the Method Result
  var useCacheData := new AssignmentStatement(newResult, new NamedLocalValue('strData'));
  // CACHE DATA NOT USED: To assign the result of our OriginalBody to the Method Result.
  var useOriginalMethodResult := new AssignmentStatement(new NamedLocalValue('resultOriginal'), newResult);

  aMethod.SetBody(Services,
    method begin
      var strData: String;
      // Get our Cache Key Name
      var cacheKey := MemCache.getKeyFromMethod(Aspects.MethodName, Aspects.GetParameters);

      try
        // See if we have anything in the cache for this key.
        unquote(getDataAssignment);
        // Replace this
        unquote(useCacheData);
      except
        on E: Exception do
        begin
          var resultOriginal: String;
          // No cache data found, execute the original method body.
          Aspects.OriginalBody;

          // Assign the result of the Original Method to a new variable.
          unquote(useOriginalMethodResult);
          // Send the result of the Original Method to the Cache for next time.
          MemCache.setData(cacheKey, resultOriginal);
        end;
      end;
    end);
end;

end.

Modifying my original code into working with the Microsoft Enterprise Caching black wasn’t particularly hard. If you haven’t worked with the Microsoft P&P Enterprise Library Caching Block before I highly recommend the Quickstart guide. The Enterprise Caching Block allows you to configure your cache using configuration file and change the backing store to suit own your needs. I would certainly recommend tweaking the expiration time and frequency of cache cleaning times before you begin.

Whilst rewriting the code of my Aspect I found it absolutely invaluable to have the Cirrus documentation wiki open and a piece of paper next to my keyboard with the approximate psuedo-code that I was intending to build with Cirrus written on it. I did actually find that despite the fact that the code I was building was not complicated, I did require a reminder of the statements and structure of it.

One additional problem that I did encounter very quickly on my modification was that I had a method which would generate a string key from the method name being called and its parameters which looked like this:

class method CacheKeyFactory.GetKeyFromMethod(aName: String; Args: Array of object): String;
begin
  var argConcat: String;

  argConcat := aName;
  for argTemp in Args do
  begin
    argConcat := argConcat + argTemp.ToString();
  end;

  Result := argConcat;
end;

Which I had intended to inject into the target class using the AutoInjectIntoTargetAttribute which as the name suggests creates the method tagged within the class you are targetting with your attribute. The problem I encountered was that I used this Attribute on a method within an IMethodImplementationDecorator attribute which meant that it worked perfectly when I applied my attribute to just one method within a class but applying my attribute to more than one meant that the AutoInjected method got injected more than once – causing a conflict (Is this a bug? I was told not but it seems odd to me).

[Update: 22/11/2009] I have reported this issue as QC: 79705. [/Update]

Therefore as a workaround, I was forced to move this key generating method into a static class elsewhere in the assembly but maybe someone can work out a way around this limitation.

I also encountered an annoying trait of the Cirrus Framework which is that some errors produce a fairly unhelpful message and lead you to a line in the Project’s build file which whilst being logical can be infuriating when you’re presented with this:

A rather confusing exception and causal code identification.

After a tiny bit of tweaking, My next iteration of the Caching Attribute looks like this:

type
  [AttributeUsage(AttributeTargets.Method)]
  MethodCacheAttribute = public class(System.Attribute, IMethodImplementationDecorator)
  private
  public
    method HandleImplementation(Services: IServices; aMethod: IMethodDefinition);
  end;

implementation

method MethodCacheAttribute.HandleImplementation(Services: IServices; aMethod: IMethodDefinition);
begin
  // Get a Reference to our Result Value
  var methodResult := new ResultValue();

  // Get a reference to our Static Key Factory.
  var cacheKeyGen := Services.FindType('CirrusCachingAspect.CacheKeyFactory');
  // Generate our cache key from the method name and it's parameters
  var getCacheKey := new AssignmentStatement(new NamedLocalValue('cacheKey'), new ProcValue(new TypeValue(cacheKeyGen), 'GetKeyFromMethod', [aMethod.Name, aMethod.GetParameterArrayValue()]));

  // Get our CacheManager Type and our CacheFactory Type
  var cacheType := Services.FindType('Microsoft.Practices.EnterpriseLibrary.Caching.CacheManager');
  var cacheFactoryType := Services.FindType('Microsoft.Practices.EnterpriseLibrary.Caching.CacheFactory');

  // Get a Reference to our Cache Instance.
  var getCacheInstance := new AssignmentStatement(new NamedLocalValue('methodCache'), new ProcValue(new TypeValue(cacheFactoryType), 'GetCacheManager'));

  // Get data from our cache.
  var getDataFromCache := new ProcValue(new NamedLocalValue('methodCache'), 'GetData', [new NamedLocalValue('cacheKey')]);

  // Cast our result from the Cache to the Result Type.
  var valueCastToResultType := new UnaryValue(new NamedLocalValue('cacheData'), UnaryOperator.Cast, aMethod.Result);

  // Assign the result of our cache request to a local variable.
  var getDataAssignment := new AssignmentStatement(new NamedLocalValue('cacheData'), getDataFromCache);

  // Assign our Cache'd data to the Method Result
  var useCacheData := new AssignmentStatement(methodResult, valueCastToResultType);

  // Add our data to the Cache for next time
  var addDataToCache := new StandAloneStatement(new ProcValue(new NamedLocalValue('methodCache'), 'Add', [new NamedLocalValue('cacheKey'), methodResult]));

  // Key not found in the cache, insert the original body and add a call to the Cache.Add() method.
  var notFoundInCache := new BeginStatement();
  notFoundInCache.Add(new PlaceHolderStatement());
  notFoundInCache.Add(addDataToCache);

  // If found in the cache.
  var ifCacheResult := new IfStatement(new BinaryValue(new NamedLocalValue('cacheData'), new NilValue(), BinaryOperator.Equal), notFoundInCache, useCacheData);

  aMethod.SetBody(Services,
    method begin
      var cacheData: Object;
      var methodCache: CacheManager;
      var cacheKey: String;

      // Get out cache instance
      unquote(getCacheInstance);

      // Generate a key for this method call.
      unquote(getCacheKey);

      // Try to retrieve the data from the cache.
      unquote(getDataAssignment);

      // If data from cache = nil then
      //    call original method
      //    add to cache
      // else
      //    return the data from the cache
      unquote(ifCacheResult);

    end);
end;

Which may look quite complex at first but when you look at the actual statements and values being passed around, you can quickly get a feel for how the code works. We can then easily apply this attribute and cache the result of any method in a class automatically like this:

type
  Flickr = public class
  private
    _username: string;
  public
    method Flickr(username: String);
    [Aspect:MethodCache]
    method GetPhotos: XmlDocument;
    [Aspect:MethodCache]
    method GetUsername: String;
    [Aspect:MethodCache]
    method GetAuthLevel(user: String): Integer;
  end;

Where GetPhotos, GetUsername and GetAuthLevel will all have their results cached automatically by our Aspect. You can see the resulting AOP’d code disassembled in the reflector below:

The RedGate .NET Reflector showing our Cirrus doctored caching code.

There is still one slight limitation in our method of key generation which is that it will currently only generate a unique key for a method with parameters if the Types of the methods parameters provide a proper implementation of ToString() that identifies them. Before you mention it, I had considered using the GetHashCode() method for this purpose but the default implementation of the GetHashCode method does not guarantee unique return values for different objects which makes it no more useful than relying on the user to implement the ToString() method.

I have made my implementation available on GitHub as the CirrusCachingAttribute where you can feel free to download and play with the source but please note that you will need to download and install the Enterprise Library from Microsoft first. I have also added a stub to the Code section on my site for the Cirrus Caching Attribute.

There is also a Standard Library of Aspects over on code.remobjects.com which provides a good set of Aspects from which you can learn more about how Cirrus works.

Before you get too hasty with building your own class generators it’s also worth noting that Microsoft’s xsd.exe tool can also be used with Delphi Prism (thanks to Jeroen Pluimers and Peter Nowotnick for sharing this tip with us).

Getting Started

In Order to get started you’ll need to reference the RemObjects.Oxygene.CodeModel.dll and add the CodeDom namespace from this plus System.CodeDom to your uses.

It is worth noting that automated code generation is like our work with the Delphi Prism AOP Cirrus framework in that the code required to create a small amount of target output code can become quite hard to read at a glance so organise it well.

We’re going to start off by creating a basic class for Saying Hello (highly innovative you understand! ) and then generating the code and writing it to a new .pas file. Our basic first steps in generating a class involve setting up the unit (with a CodeCompileUnit), the namespace (with a CodeNamespace) and the class itself (with a CodeTypeDeclaration):

namespace CodeDomGeneration;

interface

uses
  System.Linq,
  System.Reflection,
  System.IO,
  System.CodeDom,
  System.CodeDom.Compiler,
  RemObjects.Oxygene.CodeDom;

type
  ConsoleApp = class
  public
    class method Main;
  end;

implementation

class method ConsoleApp.Main;
const
  outputFile = 'uMyClass.pas';
var
  uNewUnit: CodeCompileUnit;
  MyHelloNS: CodeNamespace;
  MyNewClass: CodeTypeDeclaration;
  provider: CodeDomProvider;

begin
  uNewUnit := new CodeCompileUnit;

  MyHelloNS := new CodeNamespace('Hello');
  MyHelloNS.Imports.Add(new CodeNamespaceImport('System'));

  MyNewClass := new CodeTypeDeclaration('TSayHelloClass');
  MyNewClass.IsClass := true;
  MyNewClass.TypeAttributes := TypeAttributes.Public + TypeAttributes.Sealed;
  MyNewClass.Comments.Add(new CodeCommentStatement('This is our CodeDom created class  '));

  MyHelloNS.Types.Add(MyNewClass);
  uNewUnit.Namespaces.Add(MyHelloNS);

  // Get our CodeDomProvider
  provider := CodeDomProvider.CreateProvider('Oxygene');

  // Options.
  var options: CodeGeneratorOptions := new CodeGeneratorOptions();

  // Create our output filestream.
  var sourceWriter: StreamWriter;
  sourceWriter := new StreamWriter(outputFile);

  // Generate our code.
  provider.GenerateCodeFromCompileUnit(uNewUnit, sourceWriter, options);

  // Close our output filestream
  sourceWriter.Close();

  Console.WriteLine('Press Enter to exit..');
  Console.ReadLine;
end;

end.

If you run this code, you’ll find a new uMyClass.pas file has been generated in the output directory which contains little more than a class shell and a couple of comments: One to note that the source file was auto-generated by a tool and another to which is our own comment on the TSayHelloClass. You’ll also note that unlike the previous article, we’re using:

 CodeDomProvider.GenerateCodeFromCompileUnit();   

To Generate code from the Code Document Object Model rather than the Compile method we used last time. You could also compile directly from a CodeDom object as alluded to in my previous post on Dynamically compiling Delphi Prism code using the CodeDomProvider.CompileAssemblyFromDom method.

The Next step is to add a private field (CodeMemberField) and a public property (CodeMemberProperty) to our class with its own getter and setter methods:

  var MyNameProperty: CodeMemberProperty;
  var MyNameField: CodeMemberField;

 // Add our private field.
  MyNameField := new CodeMemberField;
  MyNameField.Name := 'fFullName';
  MyNameField.Type := new CodeTypeReference('System.String');
  MyNameField.Attributes := MemberAttributes.Private;

  // Add the public property with a Getter and Setter
  MyNameProperty := new CodeMemberProperty;
  MyNameProperty.Name := 'FullName';
  MyNameProperty.Type := new CodeTypeReference('System.String');
  MyNameProperty.Attributes := MemberAttributes.Public;
  MyNameProperty.GetStatements.Add(new CodeMethodReturnStatement(new CodeFieldReferenceExpression(new CodeThisReferenceExpression(), 'fFullName')));
  MyNameProperty.SetStatements.Add(new CodeAssignStatement(new CodeFieldReferenceExpression(new CodeThisReferenceExpression(), 'fFullName'), new CodePropertySetValueReferenceExpression()));

  // Add our two new objects to the parent code tree
  MyNewClass.Members.Add(MyNameField);
  MyNewClass.Members.Add(MyNameProperty);

It could very easy to get carried away creating an initialising your new class, methods, fields or properties and forget to .Add() them to the target CodeStatementCollection so if your new objects do not show up in the generated code, check that you have actually added them. We can now add a public SayHello method to our class which will greet the previously named entity:

  var MySayHello: CodeMemberMethod;

  // Our public method to say "Well Hi there <fFullName>"
  MySayHello := new CodeMemberMethod();
  MySayHello.Name := 'SayHello';
  MySayHello.ReturnType := new CodeTypeReference(typeof(System.String));
  MySayHello.Attributes := MemberAttributes.Public;
  MySayHello.Statements.Add(new CodeMethodReturnStatement(new CodeBinaryOperatorExpression(new CodePrimitiveExpression('Well Hi there '), CodeBinaryOperatorType.Add, new CodeFieldReferenceExpression(new CodeThisReferenceExpression(), 'fFullName'))));

  // Add our new method to the parent class.
  MyNewClass.Members.Add(MySayHello);

The Method statements that I have added here have been created on the fly and not been structured well for readability at all. As I mentioned at the beginning, you will need to structure your code carefully to ensure readability. If you run this code again now, you should see our SayHello Method as below:

method TSayHelloClass.SayHello: System.String;
begin
    exit(('Well Hi there ' + self.fFullName));
end;

You can also add statements from “snippets“, which allows you to essentially inject code as a string using the CodeSnippetExpression class:

  var snippetSayHelloMethod:  CodeSnippetExpression  := new CodeSnippetExpression('Result := Self.fFieldName');
  //Convert the snippets into Expression statements.
  var stmtSayHelloResult: CodeExpressionStatement := new CodeExpressionStatement(snippetSayHelloMethod);
  // Add it to our SayHello Method
  MySayHello.Statements.Add(stmtSayHelloResult);

Warning: Adding method statements from snippets in this manner should be used with great care as you have very little protection against a typo causing a mal-formed code output and I would not recommend generating complex code statements from the CodeSnippetExpression.

There is a Code object representation of anything that you could want to generate, you simply need to find the right class. For example, if we wanted to add a class entry point to our class then we could create one with the CodeEntryPointMethod class:

  var MyMain: CodeEntryPointMethod := new CodeEntryPointMethod();
  MyMain.Name := 'Main';
  MyMain.Attributes := MemberAttributes.Public + MemberAttributes.Static;
  var cs1: CodeMethodInvokeExpression  := new CodeMethodInvokeExpression(
        new CodeTypeReferenceExpression('System.Console'), 'WriteLine',
        new CodePrimitiveExpression('Hello World!') );
  MyMain.Statements.Add(cs1);

  MyNewClass.Members.Add(MyMain);

Conclusion

The System.CodeDom space is a very very powerful tool and one that developers used to developing native Win32 Delphi might not be aware of. You will probably be able to dream up of a number of cases where generating some of your Delphi Prism code dynamically could save you time. Use it wisely.

It is my intention that this post should introduce you to the process of dynamically compiling code and that the next part will hopefully be an introduction to the process of dynamically generating and compiling code using the .NET CodeDom.

To begin with, create a New Console Application in Delphi Prism and Add a Reference to the RemObjects.Oxygene.CodeModel assembly. For my installation, this was found in the Bin directory of the Delphi Prism program files directory.

Once you’ve done this you can use the following code:

namespace DynamicCompilation;

interface

uses
  System.Collections,
  System.CodeDom.Compiler,
  RemObjects.Oxygene.CodeDom;

type
  ConsoleApp = class
  public
    class method Main;
  end;

implementation

class method ConsoleApp.Main;
var
  provider: CodeDomProvider;
  strFileOut: string;
  results: CompilerResults;
  cp: CompilerParameters;
  strSource: String;
begin

strSource := "namespace HelloWorld;

interface

type
  ConsoleApp = public class
  public
    class method Main;
  end;

implementation

class method ConsoleApp.Main;
begin
  Console.WriteLine('Hello World.');
end;
end.";

  // Get our CodeDomProvider
  provider := CodeDomProvider.CreateProvider('Oxygene');

  cp := new System.CodeDom.Compiler.CompilerParameters;
  cp.CompilerOptions := '';
  // Defaults to false which creates a dll instead.
  cp.GenerateExecutable := true;
  strFileOut := 'C:\test.exe';
  cp.OutputAssembly := strFileOut;

  // Compile our code.
  results := provider.CompileAssemblyFromSource(cp, [strSource]);

  Console.WriteLine('Number of Errors Encountered: {0}', results.Errors.Count);
  for error: CompilerError in results.Errors do
      begin
        Console.WriteLine('{0}: {1}', [error.ErrorNumber, error.ErrorText]);
      end;
  if (Assigned(results.PathToAssembly)) then
     begin
       Console.WriteLine('Path to Assembly: {0}', results.PathToAssembly);
     end;

  Console.WriteLine('Press Enter to exit..');
  Console.ReadLine;
end;

end.

Our Test Console Output

This code should be fairly straight forward to understand but there are a few parts that are worth drawing attention to. The first is this line:

provider := CodeDomProvider.CreateProvider('Oxygene');

I originally tried to create a new instance of the RemObjects.Oxygene.CodeModel.OxygeneCodeProvider as you can when creating a CSharpCodeProvider:

            var provider_options = new Dictionary
                         {
                             {"CompilerVersion","v3.5"}
                         };
            var provider = new Microsoft.CSharp.CSharpCodeProvider(provider_options);

However in my experience calling the constructor on the OxygeneCodeProvider class merely causes a Null Reference Exception when you actually try to use a Compile method on the resulting class. It is worth noting that by replacing the string ‘Oxygene’ above with ‘VisualBasic’ or ‘CSharp’ you can obtain an instance of other language providers.

The next part worth paying careful attention to is the setup of the CompilerParameters:

  cp := new System.CodeDom.Compiler.CompilerParameters;
  cp.GenerateExecutable := true;
  strFileOut := 'C:\test.exe';
  cp.OutputAssembly := strFileOut;

This part of the code, configures the Provider to generate an executable instead an assembly (which is the default configuration) and tells the Provider where to output the resulting executable. This should be relatively straightforward and for a full reference of CompilerParameters – see the MSDN documentation on System.CodeDom.Compiler.Compilerparameters.

Those sharp-eyed amongst you may have noticed that the code that I’m compiling above does not contain any uses declarations. First we need to Reference the relevant assemblies using the CompilerParameters.ReferencedAssemblies StringCollection:

  cp := new System.CodeDom.Compiler.CompilerParameters;
  // Clear our Assembly List
  cp.ReferencedAssemblies.Clear;
  // Add a few usual suspects
  cp.ReferencedAssemblies.Add('System.dll');
  cp.ReferencedAssemblies.Add('System.Core.dll');

You can then “uses” any namespace in the referenced assemblies (be careful: There is no official .NET assembly called System.Linq.dll for example).

The final part which is worth drawing attention to is the actual compile command:

   results := provider.CompileAssemblyFromSource(cp, [strSource]);

For reference, the relevant parts of the declaration for a CodeDomProvider might look something like the following:

public CodeDomProvider = class abstract(Component)
    public function CompileAssemblyFromDom(options: CompilerParameters; [ParamArray] compilationUnits: CodeCompileUnit[]): CompilerResults; virtual;
    public function CompileAssemblyFromFile(options: CompilerParameters; [ParamArray] fileNames: string[]): CompilerResults; virtual;
    public function CompileAssemblyFromSource(options: CompilerParameters; [ParamArray] sources: string[]): CompilerResults; virtual;

You can feed the CompileAssemblyFrom methods several different files, strings, or Dom structures which might represent different .pas files that you would create when you created a project in Delphi Prism. The example below includes an additional class:

namespace DynamicCompilation;

interface

uses
  System.Collections,
  System.CodeDom.Compiler,
  RemObjects.Oxygene.CodeDom;

type
  ConsoleApp = class
  public
    class method Main;
  end;

implementation

class method ConsoleApp.Main;
var
  provider: CodeDomProvider;
  strFileOut: string;
  results: CompilerResults;
  cp: CompilerParameters;
  strSource: String;
begin

strSource := "namespace HelloWorld;

interface

type
  ConsoleApp = public class
  public
    class method Main;
  end;

implementation

class method ConsoleApp.Main;
var
  PingPong: TPingPong;
begin
  PingPong := new TPingPong;
  Console.WriteLine(PingPong.Ping);
  Console.WriteLine('Hello World.');
end;
end.";

var strSource2 := "namespace HelloWorld;

interface

type
  TPingPong = public class
  public
    method Ping: string;
  end;

implementation

method TPingPong.Ping: string;
begin
  Result := 'PONG!';
end;
end.";

  // Get our CodeDomProvider
  provider := CodeDomProvider.CreateProvider('Oxygene');

  cp := new System.CodeDom.Compiler.CompilerParameters;

  cp.CompilerOptions := '';
  // Defaults to false which creates a dll instead.
  cp.GenerateExecutable := true;
  strFileOut := 'C:\test.exe';
  cp.OutputAssembly := strFileOut;

  // Clear our Assembly List
  cp.ReferencedAssemblies.Clear;
  // Add a few usual suspects
  cp.ReferencedAssemblies.Add('System.dll');
  cp.ReferencedAssemblies.Add('System.Data.dll');

  // Compile our code.
  results := provider.CompileAssemblyFromSource(cp, [strSource2, strSource]);

  //Console.WriteLine('Generated assembly name: ' + results.CompiledAssembly.FullName);
  Console.WriteLine('Number of Errors Encountered: {0}', results.Errors.Count);
  for error: CompilerError in results.Errors do
      begin
        Console.WriteLine('{0}: {1}', [error.ErrorNumber, error.ErrorText]);
      end;
  if (Assigned(results.PathToAssembly)) then
     begin
       Console.WriteLine('Path to Assembly: {0}', results.PathToAssembly);
     end;

  Console.WriteLine('Press Enter to exit..');
  Console.ReadLine;
end;

end.

And voila.. the output from our dynamically compiled executable can be seen as below:

The output from our dynamically generated executable

If the other compiler methods available with our CodeProvider caught your eye then this leads me nicely onto my intended next steps. While generating code from a string containing your code is nice and easy, sometimes it may not be the best way to approach Code Generation.

I realise that the end result of the above could have been achieved by simply writing a file out and then executing the command line compiler but where’s the fun in that? Next time I intend on looking at generating a CodeDom tree and providing this to the Compiler (no more potentially troublesome string manipulation required).

Why would you need  to use AOP?

Many people don’t really understand why they would need to use AOP in any way. It’s true that nearly all programming paradigms support some form of separation and modularity but to see where this can quickly fall down, you simply have to look at the classic logging example which has been the staple diet of coverage of the Cirrus framework. Logging is a good example because it is likely that if your application implements logging features, then you probably have logging code mixed up in your beautifully designed business objects at various places tainting the implementation of your once clean object.

A Simple Example

For the purposes of those people who weren’t convinced on it’s usefulness from the example given. Imagine we have a very important Business object of a Type called TCustomer. We’ve been told that we need to log everything done to our Customer objects for audit purposes (and you wouldn’t want to get on the wrong side of the Internal Audit team..).  We could easily add our logging calls into every function of TCustomer but this going to require a lot of CTRL+C, CTRL+V and is a lot of identical code-repetition and shouldn’t we be striving to avoid code repetition? This might also get your local overly-sensitive Anti Copy-Paste mafia up in arms. There is another problem with simply inserting our code into each method: What happens if later on, another programmer adds another method for updating, deleting or even just saving a copy of our Customer. Internal Audit are not going to be happy. Of course, you could blame it on your inexperienced colleague but that’s not going to make much difference, it’s a team failure after all.

Had we used AOP we could have used something as simple as the Cirrus Introduction LogToMethod code, tagged our TCustomer class with a single attribute and been saved from this potential oversight:

// For the full code for this example, please see the original introductory tutorial at:
// http://prismwiki.codegear.com/en/Cirrus_Introduction
namespace MyLogToMethodAspect;

interface
uses
  RemObjects.Oxygene.Cirrus;

type
  [AttributeUsage(AttributeTargets.Class or AttributeTargets.Struct)]
  LogToMethodAttribute = public class(System.Attribute, IMethodImplementationDecorator)
  public
    [Aspect:AutoInjectIntoTarget]
    class method LogMessage(aEnter: Boolean; aName: String; Args: Array of object);

    method HandleImplementation(Services: IServices; aMethod: IMethodDefinition);
  end;

implementation

class method LogToMethodAttribute.LogMessage(aEnter: Boolean; aName: String;
  Args: Array of object);
begin
  if aEnter then
    Console.WriteLine('Entering ' + aName)
  else
    Console.WriteLine('Exiting ' + aName);
end;

method LogToMethodAttribute.HandleImplementation(Services: IServices; aMethod: IMethodDefinition);
begin
  if String.Equals(aMethod.Name, 'LogMessage',
    StringComparison.OrdinalIgnoreCase) then exit;
  if String.Equals(aMethod.Name, '.ctor',
    StringComparison.OrdinalIgnoreCase) then exit;

  // Cool use of anonymous methods here....
  aMethod.SetBody(Services,
    method begin
      LogMessage(true, Aspects.MethodName, Aspects.GetParameters);
      try
        Aspects.OriginalBody;
      finally
        LogMessage(false, Aspects.MethodName, Aspects.GetParameters);
      end;
    end);
end;

end.

Of course, you don’t need Aspect Oriented Programming in the same way as you don’t need Object Oriented Programming, we could just revert to procedural programming but as programmers we strive to separate various concerns cleanly and this is another step towards that.

What’s the catch?

The problem with separating our code in such a way is that potentially, it could be hard for a programmer unfamiliar with AOP to understand the code as the only clue of any logging activity for our target class might be a single attribute in our interface section. Our Aspect might also rely upon the underlying method in which case we could run into problems if we restructure or  move our methods around causing unintended consequences. There is also a concern that a serious bug in our Aspect code could lead to a more widespread failure in the program (as it has the potential to be applied to large swathes of code easily).

However, with careful testing and implementation these potential drawbacks can be mitigated.

Apart from Logging, what else can I use it for?

Typical uses include logging, authentication, caching and dependency injection. John Moshakis has been blogging some elegant real-life uses of the Cirrus framework such as Implementing Dependency Injection, allowing him to switch seamlessly between test and production services in an app.

My Own Journey to AOP

After the Cirrus Framework was released I wanted to try to build my own Aspect which wasn’t the logging sample provided. I had a service that retrieved a string of XML from a REST Web Service at frequent intervals which I felt could be improved with caching functionality. The Code for the Web Service and for the Cache were just test classes for the purpose of this experiment but I would imagine that you could extend this to use the The Caching Application Block from the Microsoft Enterprise Library if you wished. Normally, I could add caching to each method by modifying it like so:

method TFlickr.GetUserInformation(username: String): String;
begin
  // Do we have this information in our cache?
  if (MyCache.HasData('UserInfo_' + username)) then
  begin
    // We do, use the cache'd data.
    Result := MyCache.GetData('UserInfo_' + username);
  end
  else
  begin
    // No cache'd version, retrieve a new set of data.
    { Open our TCP Socket, call the webservice with the
      correct parameters and return the result.     }
    // Add our newly retrieved data to the cache.
    MyCache.SetData('UserInfo_' + username, Result);
  end;
end;

This method of implementation would lead to me having to put this code into each method and would lead to code repetition and possibly bugs being introduced (for example, if I forgot to update the cache key string on one method). I wondered if I could have a CacheString attribute that would allow me to automaticaly add my generic “do we have cache’d data? if so use it else carry on”  code to each method.

First of all, I tried essentially moving this code into a Method Aspect and adding a generic key function which takes the method name and method arguements and turns it into a consistent string using the Aspects.MethodName and Aspects.GetParameters methods:

WARNING! BROKEN CODE:

class method MyCache.getKeyFromMethod(aName: String; Args: Array of object): String;
begin
  var argConcat: String;

  argConcat := aName;
  for argTemp: String in Args do
  begin
    argConcat := argConcat + argTemp;
  end;

  Result := argConcat;
end;

method MyCacheAttribute.HandleImplementation(Services: IServices; aMethod: IMethodDefinition);
begin
  aMethod.SetBody(Services,
    method begin
	  var cacheKey := MyCache.getKeyFromMethod(Aspects.MethodName, Aspects.GetParameters);
	  // Do we have this information in our cache?
	  if (MyCache.HasData(cacheKey)) then
	  begin
		// We do, use the cache'd data.
		Result := MyCache.GetData(cacheKey);
	  end
	  else
	  begin
        Aspects.OriginalBody;

        // Send the result of the Original Method to the Cache for next time.
        MyCache.setData(cacheKey, Result);
      end;
    end);
end;

Unfortunately it is not quite as simple as just placing your code into the AMethod.SetBody Anonymous method. Luckily it turned out that the Cirrus documentation on the Wiki had recently been updated and I discovered the Cirrus Statements and Cirrus Values namespaces after a bit of helpful guidance from John Moshakis on StackOverflow and Twitter (thank-you for that John!). I discovered that what you are required to do in most cases is to construct your code in an almost compiler like fashion using the Statement and Values namespaces.

Eventually after playing around with the Cirrus API, I eventually ended up with the following code:

method MemCacheAttribute.HandleImplementation(Services: IServices; aMethod: IMethodDefinition);
begin
  // Get a Reference to our Result Value
  var newResult := new ResultValue();

  // Get our MemCache Object
  var cacheType := Services.FindType('AOPCacheLibrary.MyCache');
  // Setup our static methods.
  var getDataProc := new ProcValue(new TypeValue(cacheType), 'getData', [new NamedLocalValue('cacheKey')]);

  // Assign the result of our cache request to a local variable.
  var getDataAssignment := new AssignmentStatement(new NamedLocalValue('strData'), getDataProc);

  // CACHE DATA USED: To assign our Cache'd data to the Method Result
  var useCacheData := new AssignmentStatement(newResult, new NamedLocalValue('strData'));
  // CACHE DATA NOT USED: To assign the result of our OriginalBody to the Method Result.
  var useOriginalMethodResult := new AssignmentStatement(new NamedLocalValue('resultOriginal'), newResult);

  aMethod.SetBody(Services,
    method begin
      var strData: String;
      // Get our Cache Key Name
      var cacheKey := MyCache.getKeyFromMethod(Aspects.MethodName, Aspects.GetParameters);

      try
        // See if we have anything in the cache for this key.
        unquote(getDataAssignment);
        // Replace this
        unquote(useCacheData);
      except
        on E: Exception do
        begin
          var resultOriginal: String;
          // No cache data found, execute the original method body.
          Aspects.OriginalBody;

          // Assign the result of the Original Method to a new variable.
          unquote(useOriginalMethodResult);
          // Send the result of the Original Method to the Cache for next time.
          MyCache.setData(cacheKey, resultOriginal);
        end;
      end;
    end);
end;

According to the Red Gate .NET Reflector and Disassembler, this produces the following code:

    function TFlickr.GetUserInformation(username: String): String;
    var
        Result: string;
    begin
        cacheKey := MyCache.getKeyFromMethod('GetUserInformation', New(array[1] of TObject, ( ( userid ) )));
        try
            Result := MyCache.getData(cacheKey)
        except
            on E: Exception do
            begin
                // This is where we do our _ORIGINAL_ function
                resultOriginal := Result;
                MyCache.setData(cacheKey, resultOriginal)
            end
        end;
        begin
            Result := Result;
            exit
        end
    end;

This means that I can now add caching to any of my string returning web service methods in my class by simply tagging the methods that I want cached with a code attribute:

  TFlickr = public class
  private
	{code}
  public
    {more code etc, etc}
    [Aspect:MyStringCache]
    method TFlickr.GetUserInformation(username: String): String;
  end;

This works perfectly but there are a few problems with this code:

• As you can see: constructing statements using the Cirrus API (in the statements before the aMethod.setBody) doesn’t exactly make for readable code. You may wish to consider outlining each statement with psuedocode so that it is clearer at a glance what the API calls produce.
• I should be using the Cirrus Procedure Value calls for all three calls to the Static “MyCache” class but am not because I couldn’t quite get this working. Please be aware that John informs me that the method I use in the first and third instance is not the correct way to go about this.
• This exact method only currently works for System.String returning methods. There must be a way of abstracting this function to apply it to almost a method returning almost any type (if anyone has any suggestions about how this might be accomplished then, by all means post a link in the comments).

Please note that the code above is NOT intended to be a reference implementation for AOP or Application Caching but is merely intended to show you my own learning path with Cirrus and AOP. The Cirrus API is quite difficult to work with at first and can give you frustrating compiler errors but it’s worth keeping an eye on the documentation pages and as more examples appear online it will become easier to work with. You should have the Red Gate .NET Reflector on hand with its disassemble function to confirm exactly what the resulting code in your Output assemblies looks like.

If you have any constructive suggestions for my code above then please let me know. Additionally, if you think it would be useful for me to post the downloadable Delphi Prism project then please also let me know in the comments below.

Starting your own journey to Cirrus/AOP

• Delphi Prism Wiki – Cirrus Documentation – The Definitive Reference.
• Jim McKeeth’s DelphiLive! Presentation on AOP – A Good Introduction and Overview to AOP.
• Delphi Prism Wiki – Cirrus Introduction – An Introductory guide to Cirrus and AOP that will guide you into building the logging example shown in this post.
• John Moshakis’s Blog - Some Excellent Examples of real applications of the Cirrus Framework.

Jim is planning another session for the DelphiLive conference (which I really wish I could go to, check it out if you haven’t already). However when running the last tournament we encountered a number of fatal bugs in the .NET UT3 Bot library which was originally put together by Andy Sterland & James Lissiak. As a result Jim and I had been discussing the idea of porting the original library to Delphi Prism so that we could fix a few of the more serious bugs, it would also allow potential Prism Developers who were not familiar with C# to dig into the library itself. This is a project conversion diary which will outline the approaches I tried, any hurdles I encountered and a few tips for trying to avoid them when converting your own project.

I started by running the C#ToOxygene Tool on all of the source files within the project, It’s a very simple and easy to use tool that as its name implies aims to convert C# source files to Delphi Prism files. I was able to run the tool without issue on every C# source file except for 3 where for some reason it exited producing the error:  ”Error during processing: Index was out of range” (Issue logged (rather clumsily) as #37).

Having started on the basics of the translation using the conversion tool to do the grunt work I then dived into the code with the Prism Wiki and MSDN C# documentation open to make a start on correcting the 600-odd errors that the resulting project produced upon an attempted Build.

At first glance I felt that the resultant code was a little bit visually “messy” in places and I felt it might be easier to prettify the code using a Code Formatter such as the JEDI Code Format tool to clean up the auto generated code and highlight any mismatched parenthesis or similar errors. However unfortunately the JEDI tool is not compatible with Prism and therefore refused to help me. If anyone knows of a Code Formatting tool which is compatible with Delphi Prism then please let me know in the comments below.

A few other issues which I encountered with the generated code or more generally are outlined below:

Internal Keyword

The C# internal (msdn doc) keyword was not correctly translated – for this I took a trip to the Prism Wiki and looked up the Class Member Visibility Levels page to find that the equivalent level assembly is listed there (Issue #42). Note that in Delphi Prism you can also have assembly or protected or assembly and protected depending upon whether you wish the class to be visible to descendants.

The C# “this” Keyword

The C# this. (msdn doc) keyword was not correctly translated to the Delphi Prism Self. equivalent that we’re all accustomed to. This isn’t hard to spot when going through the generated code and the issue had already been logged by Anton Kasyanov (Issue #39) and should be fixed shortly.

Float Types

One class made extensive use of the float type (msdn doc) which doesn’t exist as is a built-in type for Delphi Prism so you’ll need to convert it to one of the two Float types depending upon the precision you require.

Operator Overloading

Operator Overloading is not something that Delphi developers may be traditionally used to but Delphi Prism supports this nicely. However instead of using the sign operator that C# Developers use you’ll need to lookup the operator name and declaration on the Operator Overloading Wiki Page. eg. The Equals operator is declared as so:

class operator Equal(obj1, obj2: UTIdentifier): boolean;

Differences between return, Result and exit

This should be obvious to any C# Developer but it could be easy to forget about. Don’t forget that the return C# method (msdn doc) terminates execution of the method in which it is being executed and returns to the calling method and therefore be wary of using Result blindly in an identical manner, particularly with boolean statements that rely upon this fact. Eg. Consider the following C# Code:

public override bool Equals(object obj)
{
	if (obj is UTVector)
	{
		if (this._x == ((UTVector)obj)._x &&
			this._y == ((UTVector)obj)._y &&
			this._z == ((UTVector)obj)._z)
		{
			return true;
		}
	}
	return false;
}

Clearly, if you simply replace the return false; with Result := False; you will end up with a method that always returns False because the expression will always be executed no matter what Result is set to earlier in the method. In this case I simply moved the Result := false; to the top of the method. Delphi Prism also supports the Exit keyword which also allows you to Return a result parameter. This method is a lot closer to the C# return keyword and usage but the Exit page on the Prism Wiki warns against using too many exit keywords to avoid making the code harder to maintain.

Constructors are not named

This is a rare example of where the original C# code actually looks much closer to the end Delphi Prism code than a traditional Delphi programmer might think. In C# you might have a class and constructor that might look like this:

public class UTIdentifier
{
	internal UTIdentifier(string Id)
	{
	}
}

In Prism, we have nameless constructors which means that the equivalent Delphi Prism constructor implementation might look like this:

  constructor UTIdentifier(id: String);
  begin
  end;

It is important to note that in your class interface should adhere to this rule too. eg constructor(id: String);

This was something that the C#ToPas tool also generated incorrectly. (Issue #44)

Short-Circuit Boolean Expressions

I came across the C# || operator which performs a short-circuited OR boolean evaluation of the operands. I wasn’t sure that the Delphi Prism or operator produces the same behaviour but if I read the Expression Evaluation page correctly then I believe it does (In Delphi 2009, at least, this behaviour is set through the {$B+/-} compiler flag) .

Event Assignment

The Event Assignment routine for multicast delegate type events is slightly different in Delphi Prism from what we’re used to in Delphi Win32. Looking at the Event Assignment page in the wiki we can see that the actual method for assignment is much closer to the C# equivalent and uses the same C# += and -= operators. The C#ToPas tool converted this code a little too literally converted this C# code:

this._connection.OnDataReceived += new EventHandler(DataReceived);
this._connection.OnErrorOccurred += new EventHandler(ErrorOccurred);

to this:

Self._connection.OnDataReceived := Self._connection.OnDataReceived + new EventHandler(DataReceived);
Self._connection.OnErrorOccurred := Self._connection.OnErrorOccurred + new EventHandler(ErrorOccurred)

Which produces a compiler Error that Events in Delphi Prism don’t allow access to the underlying field. You should use the += operator instead as seen on the Wiki. (C#ToPas Issue logged as Issue #45).

UPDATE: I’ve just noticed (after logging my own issue) that the event assignment issue has already been reported and has been marked as Won’t Fix (Issue #27) so it looks like you’ll need to check _every_ event assignment in your project manually.

Switch and Case Statements

The C#ToPas tool did not appear to react well at all to use of the C# switch and case statements. I can’t give you any specific advice on how to fix these because each case statement was generated slightly differently in my converted code and therefore I can only advise that you check these manually or rewrite each of these methods by hand.

Reserved Keywords

Sadly this isn’t an issue that is related to the C#ToPas tool but more of an intrinsic difficulty when converting interoperable code between languages. I encountered at least one class that made use of a few reserved words in Delphi such as begin and end – I’m still not sure what to do with these for now.

Overall Impression

Despite a few early bugs the C#ToPas Tool is a good platform to begin converting your C# code to Delphi Prism although you may wish to ensure that you have some extensive Unit Tests for your code before the main code is converted so as to ensure that any bugs introduced can be picked up on quickly (which you have anyway right?). It is also worth noting that the Delphi Prism Wiki (which now authenticates via your CDN login) has excellent coverage and is an absolutely invaluable reference for anyone working with Delphi Prism.

By the time this entry is published I suspect that Carlo will be very close to fixing some or most of the above bugs in the C#ToPas tool.

The code is nowhere near complete yet and most of the files are still straight out of the Automatic conversion and therefore will not compile in any way but I’ve put what we have so far up on the rather smooth Github site at the PrismUT3RemoteBot project which anyone can fork and push changes back to. Git is a little strange to work with at first because it’s a different mindset to SubVersion/CVS but it’s worth checking out if you haven’t already.

[UPDATE: The Prism UT3 Remote Bot conversion project has been completed since this original post and may be used during Jim McKeeth's session at DelphiLive! Germany Sept 28 - Oct 2 2009.]

Ever since the release of Delphi.NET there has been much confusion surrounding why you would choose the Delphi language for .NET Development. When Delphi.NET was released there was concern that it was not a first class member of the .NET framework and always seemed to lag 12-18 months behind the lightning fast pace of development of the .NET Framework. With Prism Delphi offerings for .NET are based upon the RemObjects Oxygene compiler which isn’t required to maintain a loose language compatibility with the Win 32 Delphi compiler and therefore is able to progress at a much faster pace.  

Still, despite this: A recent Delphi Prism related thread at StackOverflow showed that there still seems to be a general feeling that Delphi is a second class citizen in the .NET Development World. Some even seemed to suggest that the language features in Prism make it unrecognisable as Delphi. To try to dispense with this idea: I thought that I would show off some of my own favourite new language features in Delphi Prism and ones which for me make it a natural fit for .NET.  

Please note: This is not intended to be a comprehensive guide to the new language features. For that you’ll need to refer to the Delphi Prism Wiki page on Compatibility with Win 32 Delphi.

My favourite new language features which Prism brings to the table for Delphi Developers is LINQ. Olaf Monien, who I also follow on Twitter (@omonien), posted a beautifully simple example of using LINQ with Delphi Prism on his own blog and then showed how Delphi Prism can also do LINQ to SQL. I have replicated his basic example below because it also demonstrates another great language feature.

// Type Declaration
  MusicAlbum = record
  public
    Name: string;
    Artist: string;
    AlbumYear: integer;
  end;

var
  MyAlbum: MusicAlbum;
  MyAlbums : List<MusicAlbum>;
begin
// Create our Album List
MyAlbums := new List<MusicAlbum>; 

// Setup a our records
MyAlbum := new MusicAlbum;
MyAlbum.Artist := 'Kanye West';
MyAlbum.Name := '808s and Heartbreak';
MyAlbum.AlbumYear := 2008;
MyAlbums.Add(MyAlbum);  

// Execute our LINQ Query
var AlbumsLastYear := from Album in MyAlbums where Album.AlbumYear.Equals(2008); 

// Add the result to our listbox
for Album in AlbumsLastYear do
begin
  lbFoundAlbums.Items.Add(Album.Artist + ' - ' + Album.Name + ' (' + Album.AlbumYear + ')');
end;

end;

 
This code clipping also demonstrates Type Inference which allows a variable type to be inferred from the context of it’s usage. For example, consider writing the following: var MyGreatList := new List<String>; or even something as simple as var s := ‘string’;. Type Inference is a useful addition which I can see myself making extensive use of. My only concern about Type Inference is how it affect’s the readability of the code as I am used to reviewing the var section of a method for a guide to what types are used within a method.

LINQ can also be used with XML. The below example takes our previous sample and reads the data from an XML file instead: 

<?xml version="1.0" encoding="UTF-8"?>
<albums>
		<album>
			<artist>Kanye West</artist>
			<title>808s and Heartbreak</title>
			<albumyear>2008</albumyear>
		</album>
		<album>
			<artist>Kanye West</artist>
			<title>Graduation</title>
			<albumyear>2007</albumyear>
		</album>
		<album>
			<artist>Nas</artist>
			<title>Unartistd</title>
			<albumyear>2008</albumyear>
		</album>
		<album>
			<artist>Notorious OST</artist>
			<title>The Notorious B.I.G.</title>
			<albumyear>2009</albumyear>
		</album>
</albums>

var
  AlbumData: XDocument;
begin
  // Load our XML Document with a System.Xml.Linq.XDocument
  AlbumData := XDocument.Load('../../albums.xml');

  // Query for albums in the year 2008
  var AlbumsLastYear := from Album in AlbumData.Descendants('album') where Album.Element('albumyear').Value = '2008' select Album;

  for Album in AlbumsLastYear do
  begin
    var s := String.Format('{0} - {1} ({2})', Album.Element('artist').Value, Album.Element('title').Value , Album.Element('albumyear').Value);
    lbFoundAlbums.Items.Add(s);
  end;

Another new language feature that I like in principle but will completely admit to not fully understanding yet is Anonymous Methods and Delegates which make executing code with different threads much easier. Sadly in my brief testing of Anonymous methods I discovered that they are only available in projects which link to the .NET Framework 3.0 and above (and, in my case, only WPF projects). In order to execute our ListBox adding code from the first code sample as an Anonymous Delegate you can do the following:

// Add the result to our listbox
for Album in AlbumsLastYear do
begin
  Dispatcher.Invoke(DispatcherPriority.ApplicationIdle, method(MyAlbum : MusicAlbum);
      begin
      lbFoundAlbums.Items.Add(MyAlbum.Artist + ' - ' + MyAlbum.Name + ' (' + MyAlbum.AlbumYear + ')');
      end, Album);
end;

This means that the compiler declares a delegate with a signature matching our anonymous method and we have now easily executed this code within a seperate thread with a minimum of code.

There are several new language features which I personally have no use for but which facilitate the use of the Microsoft Parallels framework such as Futures and Parallel sequences. Delphi Prism also supports Generics and as well as most of the standard Delphi Win32 syntax.
 
There are also lots of small additions that aren’t .NET features per-se but demonstrate the usefulness of freeing the Prism compiler and allowing more rapid progression such as Double Boolean Expressions. I’m sure we’ve all written a statement like this before: if (cost > 400) and (cost < 600) then. In Delphi Prism this can also be written as: if 400 < cost < 600 then.

As I quickly discovered whilst going through the Delphi Prism Wiki: the language changes to Delphi Prism were easier to adapt to and to learn than I had originally imagined. The New language features gained mostly did not affect my coding style too much so any developers who were concerned that Delphi Prism is nothing like Delphi have nothing to worry about. Many of the new features are useful for compatibility with the .NET Framework and will be a natural fit for existing Delphi or .NET Developers

The Easiest way to get started is to look at the free Oxidizer tool provided on the RemObjects Wiki. The tool helps with the conversion of Delphi Win32 projects to Delphi Prism (but I’m uncertain about how it performs on Delphi.NET to Delphi Prism). The Wiki is also an excellent place to get started, particularly the pages on Delphi Win32 vs Delphi Prism which list the major incompatibilities between the two languages. 

Whilst converting my Delphi.NET Library for accessing Twitter, I encountered a few basic hints and tips which I felt I should share here:

• You need to specify the namespace keyword at the top of your unit file instead of the unit keyword. The first time I tried to compile after doing this Prism still complained about not having a namespace keyword present, this was fixed by closing the solution and re-opening.
• Delphi Prism automatically makes classes that are not explicitly marked otherwise as strict private. This meant that I had to go through my library and mark all classes that I wanted to make public. eg. TMyClass = public class(System.Object);
• The overload keyword isn’t neccesary as overloading is now implicit. This isn’t a problem at all and isn’t dificult to fix as it simply meant doing a Search and Replace for the overload keyword and removing it.
• TObject no long exists and instead needs to be replaced with System.Object which has much the same properties. 
• I encountered a few problems with the use of for .. in loops. It would seem that Delphi Prism loop variables are local to the loop and therefore should be declared at the beginning of the loop (see the for wiki page for more info). In reality this meant changing: for strItem in list do to for strItem: string in list do and then removing the strItem: string; declaration in the method var section.
• The TObject.Create([...]); constructor still exists however it is now recommended that you switch to the new Object([..]) keyword for new projects. This may come as a shock to traditional Delphi’ers who have been .Create()‘ing since the dawn of Borland but this is the construction method that sems to fit in with the .NET framework better. There is also a compatibility flag in the Project properties which allows the compiler to work some magic to allow .Create to continue to function.

These are not the only changes that you will probably need to make but I found them to be a good starting point. You should definitely consult the Prism Wiki for help in which I was able to find answers very quickly (no wading boots required!).

Lastly: My project could do with a lot of refactoring in order to take advatages of the unique language features of Prism. This will take considerably more time as it means learning the new language features first!