Archive for the ‘Delphi’ Category

Generic Types are Litter

July 28th, 2010 2 comments

The short version of this post:

Do not spread generic types around. They are ugly and primitive.

Allow me to elaborate.

Generics are great

Before we got Generics (2004 in Java, 2005 in C#, and 2009 in Delphi) the way to enforce type safety on a collection type was to encapsulate it and use delegation.

class OrderList
private ArrayList items = new ArrayList();

public void Add(OrderItem item)

// Plus lots of more delegation code
// to implement Remove, foreach, etc.

Nowadays, we can construct our own type safe collection types with a single line of code.

List<orderitem> orders = new List<orderitem>();

That alone is good reason to love generics, and there lies the problem; many developers have come to love their generics a little too much.

Generics are ugly

The expressiveness of generics comes at a price, the price of syntactic noise. That’s natural. We must specify the parameterized types somehow, and the current syntax for doing so is probably as good as anything else.

Still, my feeling when I look at code with generics is that the constructed types don’t harmonize with the rest of the language. They kind of stand out, and are slightly negative for code readability.

OrderList orders = new OrderList();
// as compared to
List<OrderItem> orders = new List<OrderItem>();

This might not be so bad, but when we start to pass the constructed types around they become more and more like litter.

List<OrderItem> FetchOrders()

double CalculateTotalSum(List<OrderItem> orders)

void PrintOrders(List<OrderItem> orders)

Besides being noisy, the constructed types expose implementation decisions. In our case the list of orders is implemented as a straight list. What if we found out that using a hash table implementation for performance reasons would be better? Then we’d have to change the declaration in all those places.

Dictionary<OrderItem, OrderItem> FetchOrders()

double CalculateTotalSum(Dictionary<OrderItem, OrderItem> orders)

void PrintOrders(Dictionary<OrderItem, OrderItem> orders)

Comments redundant.

Generics are primitive

A related problem is that the constructed generic types encourage design that is more procedural than object-oriented. As an example, consider the CalculateTotalSum method again.

double CalculateTotalSum(List&amp;amp;amp;lt;OrderItem&amp;amp;amp;gt; orders)

Clearly, this method belongs in the List<OrderItem> type. Ideally, we should be able to invoke it using the dot operator.

// instead of

But we cannot make that refactoring. We cannot add a TotalSum method to the List<OrderItem> type. (Well maybe we can if we make it an extension method, but I wouldn’t go there.) In that sense, constructed generic types are primitive types, closed and out of our control.

So we should hide them

Don’t get me wrong. I use generics a lot. But for the previously given reasons I do my best to hide them. I do that using the same encapsulation technique as before, or – at the very least – by inheriting the constructed types.

class OrderList : List<OrderItem>
  double TotalSum()

So, the rule I go by to mitigate the downsides of generics, is this:

Constructed types should always stay encapsulated. Never let them leak through any abstraction layers, be it methods, interfaces or cl

That is my view on Generics. What is yours?



Just to be clear, the beef I have with Generics is with constructed types alone. I have nothing against using open generic types in public interfaces, although that is more likely to be a tool of library and framework developers.

The King is Challenged – By the Uncle

April 9th, 2010 No comments

According to Tiobe Programming Community Index as of April 2010, Java is no longer the most popular programming language. C is; Not due to a sudden increase in popularity of C, but rather a cause of Java’s ongoing decline.

After more than 4 years C is back at position number 1 in the TIOBE index. The scores for C have been pretty constant through the years, varying between the 15% and 20% market share for almost 10 years. So the main reason for C’s number 1 position is not C’s uprise, but the decline of its competitor Java. Java has a long-term downward trend. It is losing ground to other languages running on the JVM. An example of such a language is JavaFX script that is now approaching the top 20.

It’s important to point out, thought, that only the language part of Java is losing ground. As Tiobe Software indicates in their comment, the JVM is as hot as ever with all kinds of cool language evolution occurring.

Another interesting note to make about the april index is that Delphi is once again among the top ten. I’m really happy about that, although it means my old prophecy of a hasty decline kind of puts me in the corner (although I’ve already taken it back).

A third point is the giant leap of Objective-C, from 42:nd to 11:th most popular language. This is a combination of iPhone’s popularity and the fact that Objective-C is the only OO alternative allowed on that platform, besides C++.

The Tiobe Programming Language Community Index chart of april 2010


Categories: Delphi, java, opinion Tags:

Delphi on Win32 Gets Attributes

August 18th, 2009 2 comments

News on new features in the next version of Delphi keeps coming in. So far nothing really exciting has been announced, until Delphi on Win32 gets Attributes.

Source code meta data may seem like a tiny addition but it is truly huge. The fact that Java “stole” attributes from .Net (and called them annotations) is an indicator of its importance. The greatest benefit is that it allows for language extension without extending the language, and possible use cases are endless.

For me, this feature alone is a reason to upgrade.

Method Reference Events? Nah, Not Yet.

June 5th, 2009 No comments

In my previous post I discussed the problem that method pointers aren’t able to store references to anonymous methods. Unfortunately that limitation makes anonymous methods less useful since they can’t be used to set up event handlers on the fly, like so:

// Wouldn't it be great
// if we could do something
// like this?

Memo1.OnKeyPress :=
  procedure(Sender: TObject; var Key: Char)
    Key := Chr(Ord(Key) + 1);

One thing I wasn’t aware of when I wrote that previous post is that while method pointers can’t be used to store anonymous methods, the opposite is true: Method references can indeed store both anonymous methods and instance methods. Many thanks to Barry Kelly who pointed it out to me in a comment.

Could this be the way to go? Shall we all start using method references instead of method pointers when we declare the events of our components from now on? Let’s take a look shall we? But just so that we’re clear with what we mean – there are many ways to say the same thing – here are the definitions I’m using in this post.

First of all, when I say method I mean either a function or a procedure, and it can be any of the types below. This is different from the common definition stating that methods are subroutines associated with either a class or an object.

Plain methods

These are functions and procedures declared outside the context of a class.

procedure PlainProcedure;
  // Has no Self pointer

Instance methods

Functions or procedures associated to an object instance

Procedure TSomeClass.InstanceProcedure;
  // Self is an instance of TSomeClass

Class methods

Functions or procedures associated to a class. In other languages also called static methods.

class procedure TSomeClass.ClassProcedure;
  // Self is TSomeClass

Anonymous methods

Functions or procedures declared as they are assigned in an execution context. These methods capture the surrounding context and may use local variables and arguments even if they’re out of execution scope.

  function(Item1, Item2: TSomeItem): Integer;
    if Item1.Value &amp;gt; Item2.Value then
      Result := 1
    else if Item1.Value &amp;lt; Item2.Value then
      Result :=  -1
      Result := 0;

For these four types of methods there are three reference types to store pointers for later invocation of the methods.

Plain method pointer

type TPlainMethodPointer =
  procedure(ASender: TObject);

Method pointers

type TMethodPointer =
  procedure(ASender: TObject) of object;

Method references

type TMethodReference =
  reference to procedure(ASender: TObject);

This compatibility graph shows what method types can be stored with the respective reference type.

Plain Instance Class Anonymous
Plain method pointer YES no no no
Method pointer no YES YES no
Method reference YES YES YES YES

From this graph we can see that the Method reference type is the unifying type that can store all types of method references. It seems like the way to go is to embrace Method references and render the other reference types obsolete. Is it possible? The answer is yes but no.

Take the event example of my last post. The VCL can not be changed to utilize Method pointers for backward compatibility reasons (like the widespread use of TMethod casts) so there’s nothing to do about it there. But what about our own components, and components created from now on?

  TNotifyMethod = reference to procedure(Sender: TObject);

  TMyComponent = class(TComponent)
    property OnChange: TNotifyMethod read FOnChange write FOnChange;

Well, it works fine as long as you set up the event handlers (OnChange in the above example) dynamically, but the method reference type events do not play well with the Delphi 2009 IDE. The object inspector doesn’t recognize possible event handlers and won’t create one automatically I you double click the event property. If you try to force the assignment by giving the name of an existing event handler method explicitly, the IDE throws an ugly Invalid Property Error Dialog.

Invalid property error

As much as I’d like to be able to assign anonymous methods as event handlers to my components’, I’m not prepared to sacrifice the IDE integration. Hopefully CodeGear will fix this issue in future releases but until then anonymous methods will remain less useful than they could be.


Categories: Delphi, opinion, programming Tags:

CodeGear, Please Fix the Anonymous Method Assymetry

June 3rd, 2009 4 comments

As I noted in my previous post, anonymous methods is a big new feature in Delphi 2009 for the Win32 platform. While “closures” is natural and much appreciated in other languages, most notably Ruby, the Delphi community is still a bit reluctant and hesitant. Segunda Feira put words on it in his post on the subject.

I am still not convinced that this convenience is worth getting all that excited about – It has not enabled anything that was previously impossible, nor even especially difficult either to implement or to understand


anonymous methods should be used only when you absolutely have to, and so far I have not yet seen an example where anonymous methods are the only way to achieve anything

I agree that more often than not a problem can be solved with equal elegance using a pure object orientated approach, but there are situations where anonymous methods may actually be the better alternative. One situation that comes to mind is the setting up of test fixtures.
Say, for instance, that we want to test the event firing mechanism of a component. An easy way to set this up could be like the following.

procedure TestSomeComponent.TestOnChange;
  SUT: TSomeComponent;
  OnChangeFired: Boolean;
  OnChangeFired := False;
  // Set up the fixture
  SUT := CreateTheComponentToTest;
  SUT.OnChange :=
    procedure(ASender: TObject)
      OnChangeFired := True;
      CheckSame(SUT, ASender, 'The Sender event argument should be set');
  // Perform operation
  SUT.Text := 'Some text';
  // Check the result
  CheckTrue(OnChangeFired, 'Setting the Text property should fire the OnChange event');

The above code checks that the component’s OnChange event is fired when the Text property is set, and that the component is set as the Sender reference to the event handler. Except for being more compact, the biggest advantage to using anonymous methods in this scenario is that we avoid the obscure test smell and that we don’t have to clutter our test class with an instance variable (like FOnChangeFired) to identify if the event was really fired or not.

The only problem is: it doesn’t work. Why? Well, because the OnChange property is most likely of an instance method reference type (i.e. TNotifyEvent), meaning it doesn’t accept a references to an anonymous method even if it has the same signature.

type TNotifyEvent = procedure(ASender: TObject) &lt;strong&gt;of object&lt;/strong&gt;;

For our code to compile we need to redeclare TNotifyEvent and remove the “of object” keywords and instead use the method reference type.

type TNotifyEvent = &lt;strong&gt;reference to&lt;/strong&gt; procedure(ASender: TObject);

But of course, that’s not an option. It would mean that the traditional way of setting up an event handler (by using an instance method) would not work.

I see a definite problem with how the Delphi language explicitly forces you to distinguish between instance methods (and class methods for that matter) and anonymous method references, even though they share the same signature.
This is most unfortunate since I feel that the situations where we’d like to support both kinds of event handlers are quite common. And with the current semantics we have to use code duplication in order to achieve that. Like the two Synchronize methods of the built in TThread class.

In Delphi 2009 an overloaded variant of the TThread.Synchronize method was introduced, one that make use of anonymous methods. Here are snippets from that code:

  TThreadMethod = procedure of object;
  TThreadProcedure = reference to procedure;
  class TThread = class
    procedure Synchronize(AMethod: TThreadMethod); overload;
    procedure Synchronize(AThreadProc: TThreadProcedure); overload;

The two methods have almost identical implementations. The only real difference is the type of the argument.

procedure TThread.Synchronize(AMethod: TThreadMethod);
  FSynchronize.FThread := Self;
  FSynchronize.FSynchronizeException := nil;
  FSynchronize.FMethod := AMethod;
  FSynchronize.FProcedure := nil;

procedure TThread.Synchronize(AThreadProc: TThreadProcedure);
  FSynchronize.FThread := Self;
  FSynchronize.FSynchronizeException := nil;
  FSynchronize.FMethod := nil;
  FSynchronize.FProcedure := AThreadProc;

I may be overly sensitive, but code like that really disturbs me. Unfortunately it gets worse. If we follow the execution chain down into the Synchronize class method that is invoked by the two, we find this.

class procedure TThread.Synchronize(ASyncRec: PSynchronizeRecord; QueueEvent: Boolean = False);
  SyncProc: TSyncProc;
  SyncProcPtr: PSyncProc;
  if GetCurrentThreadID = MainThreadID then
    if Assigned(ASyncRec.FMethod) then
    else if Assigned(ASyncRec.FProcedure) then
    end else

It would be a lot nicer if the two reference types were joined under a common reference type. And I can’t see why it couldn’t be done. When I look at the “of object” keywords I get a feeling that the language is leaking compiler implementation through the language interface; information that is indifferent to the developer. What matters from a callers’ perspective is the method signature, not whether the method has a self pointer or not.

I hope CodeGear recognizes this problem and find a way to clean this assymetry from the language. Anonymous methods would be so much more useful if they do.


Welcome Back Delphi

February 9th, 2009 35 comments

Several years ago I said goodbye to the programming language in which I took my first stumbeling steps as a coder. I had moved on and there were no reasons to believe I’d ever go back. I was wrong. A reason emerged and Delphi 2009 now has a place, both in my computer – and in my heart.

Delphi 2009 comes with a great IDE

A sort of homecoming

Firing up the new IDE from CodeGear with Delphi for Win32 felt a lot like coming home. The outstanding graphical editor was there as was the lightning fast compiler. Visual Studio is great in many ways but it can’t compete with CodeGear’s RAD Studio when it comes to speed and rapid application development.

Not only that, the language (Object Pascal) has finally woken from its stagnated state and is getting increasingly modern. It now implements, for instance, closures (anonymous methods) which is quite rare for a non garbage collected language.

  TClosureProc = reference to procedure(AMsg: string);

function CreatePrefixedWriter(APrefix: string): TClosureProc;
  Result := procedure(AMsg: string)
    WriteLn(APrefix + AMsg);

  Log: TClosureProc;

  Log := CreatePrefixedWriter('Closure Test: ');
  Log('Write this');
  Log('And this');

The above program should produce the following output.

Closure Test: Write this
Closure Test: And this

I gotta wear shades

I am not the only one being thrilled with the rebirth of Delphi. A look at the TIOBE Programming Community Index for February shows that Delphi is the 9th most popular programming language, with a steady increase. That is a lot better than the 15th position a year and a half ago. At that time Delphi felt like a marginalized language with little promises for the future; Now it feels alive and vibrant.

Since the magic is back, I think I’ll stick around for a while.


D doesn’t have real closures

September 11th, 2007 12 comments

Note: This article was written before D got full closure support.

Delegates are something that gives me mixed feelings. While I used to embrace them in Delphi and Object Pascal, I now find them difficult to get used to in C#. I guess that is because they introduce a little of the functional programming paradigm into an otherwise object oriented environment.

Don’t get me wrong, I do find delegates powerful and I use them whenever I see fit. It’s just that they bug me, like a badly-pitched note in an otherwise perfect chord. In that respect I am much more fond of the inner classes of Java.

The D Programming Language, my favorite pet at the moment, has support for both delegates and inner classes, thus providing the best of both worlds. And since D is a multi paradigm language with support for functional programming, its delegates are justified.

The semantics of D delegates are somewhat different from that of C#. For instance, C# delegates may bind to both static and non-static methods, while D may bind to non-static methods only. But on the other hand, D delegates may also bind to inner functions, which makes them look a lot like closures.

bool retry(int times, bool delegate() dg)
  int tries = 0;
  while (tries++ < times) {
      return true;
  return false;

// Example usage
retry(3, {
  writefln("Password: ");
  char[] buf = readln();
  return (buf == "secretn");

In order to be a real closure a delegate is required to keep variables that are bound from the surrounding environment alive, even if the program has left their scope. For example, consider the following program.

int delegate() countdown(int from)
  int current = from;
  int countdown_helper() {
    return current\-\-;

  return &countdown_helper;

int delegate() dg = countdown(10);
dg(); // should return 10;
dg(); // should return 9;
dg(); // should return 8;

The countdown function returns a delegate that refers to the inner function countdown_helper. Counter_helper binds the variable current from it’s parent by returning its value and decreasing it by one.

So, if D’s delegates were real closures the first invocation of the delegate in the above example should return 10, the second 9, followed by 8, 7, and so on. But in reality they produce bogus values like 4202601 or 4202588. The reason is this: D doesn’t implement real closures. The variable current is invalid because the program is no longer executing the countdown function when countdown_helper is invoked via the delegate.

So D doesn’t have real closures, is that a big deal? No! In my opinion real closures are not important for languages that are not pure functional. The creators of D shouldn’t waste their resources on this feature since it brings little value but lots of implementation complexity. The energy is better spent on features like multicast delegates. Those would bring value in the form of convenience, and I hope future versions of D will incorporate them.

Complete versions of the code samples in this post can be found here and here.

Rest In Peace Delphi

September 2nd, 2007 28 comments

It’s not without sadness I see that what used to be my favorite language has taken a big dive in popularity recent years. Now Borland Delphi is only the 14th most popular programming language according to TIOBE Programming Community Index as per august 2007. That is five ranks lower than one year ago, and far from it’s golden days in the mid 1990’s.

Delphi was really a great language to work with. In the early days it was a strong, even leading power in the programming community. It gave us one of the first RAD environments, which sure as hell was more visual than Visual C++ and Visual Basic, its competitors at the time.

But the popularity decline didn’t come as a surprise. It started with Microsoft snatching Anders Hejlsberg, the compiler genius who created Delphi’s predecessor Turbo Pascal. Following that, the increasingly lower quality releases and the name changing mess. For some unintelligible reason Borland changed its name to Inprise, only to change it back a couple of years later, most likely due to an internal revolt. Slowly but steadily even the most devoted started to leave for other, obviously better, alternatives.

Last year Borland announced that they were selling all of its development tools, including Delphi. It long looked as if Delphi would be brought back under the name of Turbo Delphi, but the sale was canceled. Instead the development tools were spun off into a new company, owned by Borland. Since then Delphi 2007 for Win32 has been released, the best release in many many many years. They really did shape up, but I’m afraid it’s too late. The magic is gone and I have moved on.

Farewell my friend.