Posts Tagged ‘Generics’

I am presenting at ADUG Sydney in July, but come anyway as there will be pizza.

I’ll be presenting at the July ADUG Sydney meeting. I’ll be giving a practical introduction to the generic collection classes in Delphi, covering the different collections (TList, TQueue, TDictionary, etc) and also some common capabilities across the classes (such as sorting, searching, comparators, enumerators, etc). Even if you haven’t yet got your head around generics in Delphi, my aim is that you can walk out knowing when and how to use these classes.

It’s also the 10th anniversary of the founding of the ADUG Sydney chapter, so come along for either reason and have some pizza.

Generic Interfaces in Delphi

Most of the examples I’ve seen of Generics in Delphi, use classes containing a generic type. However, while working on a personal project, I decided I wanted an Interface containing a generic type.

The project uses an in-process publish/subscribe mechanism, and I wanted a subscriber to have a separate Receive method for each event type, rather than a single method which contained a big case statement with branches for each event type. Equally, however, I didn’t want to have to define an interface type for each event type. What I wanted was to have a generic Subscriber interface, that took the event type as a parameter.

However, I had no idea if I could define a generic Interface, let alone implement one. Even assuming I could do both of those things, would Delphi be able to resolve the correct Receive method to invoke? Only one way to find out….

NB: In this example, I’ve stripped out most of the pub/sub stuff, just leaving the pieces needed to show the generic interfaces. I’ll write about the other pieces over the next few posts.

First, I implemented a few sample events. The contents of these are not that interesting:

Then, I defined a generic interface

This is the interface that will need to be implemented by my subscribers in order to receive events of a particular type. Note, the type of event is set up as a generic type T.

Then, my subscribers need to implement an interface for each Event type they want to receive, however because it is a generic interface, it’s pretty straight-forward:

Note there’s no definition of a ISomeEventSubscriber and a ISomeOtherEventSubscriber interface, we can just use ISubscriber<T> and pass the type in in-place. We just need to implement the necessary overloaded Receive events.

You can see the rest of the code in the associated test project, but the above shows you the main aim. Implementing multiple interfaces, each with a strongly-typed Receive event, without actually having to define each of those interfaces.

So, does it work? Well, at my first attempt, no, it didn’t. No matter what type of Event I passed in, or via what interface, it always invoked the last Receive method.

dunit_generic_interfacesRule of life #37: If it’s a choice between Malcolm having screwed up or the Delphi compiler architects, it’s probably Malcolm’s fault.

Yes, my bad. Barry Kelly eventually pointed out the error of my ways. I’d originally defined the generic Interface with a GUID. Habit, really. However, this meant that both ISubscriber<TSomeEvent> and ISubscriber<TSomeOtherEvent>, and indeed any other interface I defined off this generic interface, would have the same GUID. This combined with the fact that I was using an “as” cast to get the Interface reference from the TMySubscribingObject instance, confused Delphi into always giving me the same Interface reference.

Drop the GUID and drop the “as”, and it all worked beautifully.

In future posts I’ll show the other side of the equation, the Publisher, as well as the Event Broker in the middle. One other nice side-effect of indicating the events a class is interested in, using interfaces in this way, is that the event broker can simply inspect the interfaces implemented by a subscriber to know which events they are interested in subscribing to.

Storing code in a collection : TDictionary and Anonymous Methods

In my earlier post, I mentioned you could use the new generic collection classes in Delphi 2009 to store anonymous methods instead of data. I wanted to try this out so I came up with the scenario of implementing factory classes as an excuse to experiment.

Factories can be a very useful way to centralise the creation logic for classes. Very often you see it when you have a base class and a whole bunch of different descendant classes and you want to do the creation in one place. Let’s say you have a reporting application. You may have a base report and a bunch of descendant reports, and you want to enforce some consistency over property values for the different reports that are set at the time of creation. Having these spread around every different place a report could be created may be error-prone. Alternatively, maybe you want to get away from the massive if…then..else blocks you often see in this situation. A Report Factory can give you one place to make sure all reports get created in the certain way, and also let the client code simply request a report by name and have the correct concrete report class created for them.

Problem is usually this means writing a new factory each time you want this, plus creating factory mapping classes to register each concrete report. This is not only a whole bunch of effort and unnecessary classes, it’s more new code to debug.

Instead, I thought I’d try creating a single factory class, that uses Generics to allow you to change the key used to request an instance, and that uses Anonymous Methods to do the creating so as to avoid the necessity for mapping classes. Sticking with my report scenario above, here’s how I wanted to instantiate it:

Where the first generic parameter is the type of the key I will use to request a report, in this case a string representing the report name, and the second is the base type I want the Factory to return.

Here’s how I wanted to register new concrete implementations:

You simply pass in the key value and the anonymous method that will be invoked to do the creation. Lastly, I want to retrieve a particular instance of my report by calling GetInstance on the factory passing in the key value.

Remember however, the type of the key value and the base type of the returned objects should be configurable via generic parameters.

Here’s the class definition I came up with:

As you can see, TKey is the name of the generic parameter representing the type I want to use to request a concrete instance of the base type specified in TBaseType.  RegisterFactoryMethod lets you register an anonymous method of type TFactoryMethod which as we already discussed will do the creating, and there is a matching UnregisterFactoryMethod to remove a key\method pair. GetInstance is there, taking the generic parameter TKey and returning an instance of the base type. There are also a couple of methods to check if a particular key is already registered and another to return the number of registered keys.

Nothing there is terribly interesting if you’ve already played with generic types. However, for me the interesting part is I’m storing the key/method pairs in a TDictionary<TKey, TFactoryMethod<TBaseType>>.  Storing the anonymous method and the key in the dictionary is pretty straightforward:

and retrieving it and executing it is equally so.

With that, we’ve got a very reusable Factory class, so I should have no excuse for avoiding them in the future. Of course, this is a fairly simplistic implementation, it doesn’t handle pipelining during the creation process for example, but this would be relatively straight-forward to add with more anonymous methods stored in a TList<T> for example.

Anyway, hopefully this little experiment has sparked some thoughts in you. The source for both the class and a client implemented as unit tests is available from my delphi-experiments repository on github.

Meanwhile I’m off to do some more playing. Next post will probably be the Pooling example I mentioned earlier but somehow forgot to post.

A TDictionary explanation

On the recent Delphi 2009 roadshow in Australia, I had a few people ask me about the new TDictionary<TKey, TValue> container in Generics.Collections. If you haven’t played with it yet,  Roland Beenhakker has a nice write up on using it, but most of the questions I was getting were not about how to use it, but about what it’s for.

The way I try and explain it is by stepping back and looking at collections that people already are used to. Leaving implementation details aside, a lot of the Delphi collections store values and let you retrieve those values using a key.

For example, a TStringList lets you store strings indexed by an integer value. So in this case, the value would be a string and the key would be an integer. A TList lets you store pointers and retrieve them using an integer. Again, the key is an Integer, the value is a pointer.

The next step is to think about TList<T>. It’s not that different, the key is still an integer, just the value can be parameterised using generics.

If you’re ok with that, then a TDictionary<TKey, TValue> is pretty easy to understand. It’s a generic container that lets you parameterise not only the value, but the key also. So, to get somewhat similar behaviour to a TStringList, you could use a TDictionary<integer, string>. Now, of course the implementation details of how TDictionary would store those strings is wildly different to a TStringList, but in terms of understanding it, I think it helps.

Equally, a TList<T> might be replaced in broad terms with a TDictionary<Integer, T>, with T being whatever type you like.

The really cool thing though, is that the key part does not have to be an Integer. You could instead of TDictionary<Integer, String> do something like TDictionary<string, string>, so a string could be retrieved by using another string as a key. If you’re trying to think of an example of that, what about the TDictionary’s real world namesake, a dictionary. The key string would be the word, the definition would be the Value.

Further, it could be TDictionary<TGuid, TState>, where you might be using a GUID as a sessionID to retrieve an object that stores your session state in some sort of distributed system.

An interesting take on this is to use a TDictionary to store code in the form of anonymous methods. Anonymous methods are defined as types, so no reason they can’t be stored in a collection just like data. I find this really interesting. If you’re a fan of using table-driven development to replace convoluted if..then…else or case statements, this might spark some ideas. In fact in my next blog post I’ll show an example of a generic Factory implementation that uses a TDictionary internally to store anonymous factory methods.

Anyway, there is a lot more to know about TDictionary’s, such as hashing functions, comparers, etc, but hopefully this has at least given you a high-level understanding of where you might look at using them.

Delphi 2009 : TQueue<T>.Dequeue vs TObjectQueue<T>.Dequeue

I was poking around inside Generics.Collections the other day while writing some code for a future post on pooling, and I came up against something puzzling.

Generics.Collections has a class called TQueue<T>, which is a generic version of the classic first-in-first-out datastructure. The nice thing of course is that it can now be made type-safe by specifying a type parameter. If you’ve ever looked at a queue, such as the non-generic one that ships with Delphi already, or even thought about a queue datastructure, looking at TQueue<T> will not hold many surprises.

Generics.Collections also has a class called TObjectQueue<T>, which descends from TQueue<T> and adds object ownership (ie. the queue will destroy any objects it holds when you destroy it). This is implemented using an interesting looking notification process that probably deserves investigation in a future post, but again, the object ownership concept should be one many Delphi developers would be familiar with from TObjectList, etc, in previous versions of Delphi.

TQueue<T> has a function called Dequeue which returns the front item off the queue. The signature looks like this:

However, when I came to use TObjectQueue<T> its Dequeue method looks like this:

 

That’s right, a procedure. Internally it still takes the front item off the queue, in fact all it does is call the inherited TQueue<T>.Dequeue, but it doesn’t give it back to you.

I have to admit, my initial reaction to this was to assume I’d navigated to the wrong class so I went back to the starting point and walked my way through it again. Nope, still a procedure. No matter how I navigated to it, it wouldn’t turn into a function.

At this point I took the dogs for a walk and thought about it some more. When I got back, unfortunately, it was still a procedure. Further, after working through the notification code a little, it turns out that not only does TObjectQueue<T>.Dequeue take the front item off the queue and not give it back to you, it also Frees the item.

Now, I’d love to tell you that after careful examination of the rest of the code I discovered what was going on but that would be complete bollocks. Instead, I dashed off an email to Barry Kelly.

The answer comes down to the fact that because TObjectQueue<T> owns the objects, you need the ability to do two different things:

  • Remove the front item from the queue and have it automatically destroyed by its owner, the queue. Maybe this is after you’ve looked at it using Peek and decided you don’t want it. This is what TObjectQueue<T>.Dequeue is for.
  • Remove the front item from the queue, and have it returned to you. Part of this is that it will be removed from the queue’s ownership and it becomes your responsibility to free. This is what the method Extract is for, which to be honest I didn’t notice was there, and is in fact defined up on the TQueue<T> as well.

If you think about the names Dequeue vs Extract, this kind of makes sense. Some small part of me still finds it a little disconcerting that a function turns into a procedure between TQueue<T> and TObjectQueue<T>, but I’m mostly over it by now. Chances are if I’d stumbled upon Extract before Dequeue, none of this would have occurred. Anyway, I changed my pool code to use Extract instead of Dequeue, all my unit tests passed and I was free to go watch the Brisbane Broncos get robbed of a spot in the Rugby League finals.

Anyway, I hope this will help some future poor soul googling away to try and find out why Dequeue changes from a function to a procedure.

Anonymous Methods, Generics and Enumerators

I’ve been playing around with Anonymous Methods in Delphi 2009 a little bit lately, and I thought one of my experiments might be worth sharing.

I decided I would try to extend TList<T> so that when you enumerate over it in a for..in loop, not every item would be returned. Specifically, only items that passed a filter criteria would be returned, and I would use an anonymous method to specify the filter criteria.

This actually turned out to be kind of fun, as I got to play with Enumerators, Generics and Anonymous Methods all in one fairly short piece of code.

So, first I looked at TList<T>. I was hoping there was some way I could specify that it should use a different Enumerator than the default, but unfortunately I could not find a way. So I descended from TList<T> to create a TFilteredList<T> to:

  • add a couple of methods, ClearFilter and SetFilter, which I’ll come back to later
  • define TFilteredEnumerator<T>
  • reintroduce the GetEnumerator method to create an instance of TFilteredEnumerator<T> instead of TList<T>’s standard TEnumerator<T>

I also declared an anonymous method type called TFilterFunction<T> which takes a parameter of type T and returns true or false depending on whether the parameter passed or failed the filter criteria respectively.

Here’s the definition:

Most of the methods on TFilteredEnumerator<T> are not terribly interesting. The constructor takes a reference to an instance of our TFilterFunction<T> anonymous method, which it stores in the FFilterFunction field. This constructor gets called from the aforementioned GetEnumerator method of TFilteredList<T>.

Most of the hard work is done by the MoveNext method, which looks like this:

It is invoked when the Enumerator wants to move to the next item in the List, returning True if it does this successfully, otherwise returning False.  In this case, it:

  • first checks to see if we’re already at the end of the List, in which case it bails out returning False, we’re at the end of the list.
  • otherwise, it keeps incrementing the position until either we’re passed the last item or we hit an item that passes our filter criteria.

ShouldIncludeItem invokes our FIlterMethod if one is defined, passing in the current item in the list. It looks like:

The following code creates a TList<TPerson> and loads it up, then enumerates over each TPerson in the list that is older than 18. You can see the call to SetFilter where we specify the anonymous method that will do the actual filtering. It then clears the filter and enumerates over all the TPerson objects.

 

This produces the following output:

————— Filtered Person List —————

Name = Fred Adult, Age = 37

Name = Mary Adult, Age = 18

————— Unfiltered Person List ————-

Name = Fred Adult, Age = 37

Name = Julie Child, Age = 15

Name = Mary Adult, Age = 18

Name = James Child, Age = 12

The generics come into play so that I can use the same list for something other than TPerson objects, in the example below, Integers:

Now, I’m not sure that I really want to write my code like this. I like the fact that there’s a nice separation between the code that decides which items to act on, and the code that actually acts on them, rather than having them all jumbled together inside the for..in loop.

Ironically, that’s also the bit that I don’t like, as I can see that the filter code could possibly be overlooked by someone not familiar with anonymous methods, and think that we were acting on all the items in the list.

Yet again, I want to have my cake and eat it to.

However, as I said at the start this was an experiment to teach me a bit more about anonymous methods, so from that point of view it worked, and hopefully you got something out of it as well.

You can download the code from my delphi-experiments repository on github.

Nullable Types in Delphi

I was traveling a bunch over the last two weeks, USA, Japan and Korea. In Osaka, I did a session on Generics for the Japan Developer Camp.

Afterwards, I was having a further play with Highlander and Generics and stumbled across something rather nice. Maybe everyone else is aware of this already, but the new Generics support in Delphi for .NET also gives us access to Nullable types. So the following code:

produces the following output in the Listbox:

false

true

18

I’m currently reading through Professional .NET 2.0 Generics to get a better understanding of all the possibilities, but already I’m getting excited by what this allows. I’ll post more as I explore further.


Now, all we need do is to deliver Tiburon to give me Generics in Win32, and I’ll be a happy boy.

Update : Hallvard has written up a good overview of generics in Highlander here