Part 1: Why use Delphi over C#?

I was chatting with Tim,and he’s trying to append an ArrayList to another ArrayList.

One would assume you can do something like, B.CopyTo(A) unfortunately, it doesn’t work because CopyTo expects a parameter of Array. So if you try B.CopyTo(A.ToArray), it doesn’t really work either.

ArrayList A, B;
A = new ArrayList(3);
B = new ArrayList(5);
for (int i = 1; i < 4; i++)
A.Add(i);

for (int i = 4; i < 8; i++)
B.Add(i);

B.CopyTo(A.ToArray());

Why can’t you just perform B.CopyTo(A) naturally? Did someone forget to declare public virtual void CopyTo(ArrayList)?

Well, Delphi’s class helper to the rescue. In Delphi’s documentation, "A class helper is a type that - when associated with another class - introduces additional method names and properties which may be used in the context of the associated class (or its descendants)."

C# 3.0 of course has extension methods, which is actually Delphi’s class helpers in disguise. And both class helpers and extension methods were invented by the same person (or group of people), Charles Jazdzewski (commonly known as Chuck Jazdzewski, who was the previous Delphi Architect), who has moved on to Microsoft to work on XAML. But C# 3.0 isn’t here yet.

In C#, if we wanted to add an ArrayList to another, the code would be:

static void Main(string[] args)
{
ArrayList A, B;
A = new ArrayList(3);
B = new ArrayList(5);
for (int i = 1; i < 4; i++)
A.Add(i);

for (int i = 4; i < 10; i++)
B.Add(i);

foreach (object I in B)
A.Add(I);

foreach (object I in A)
Console.WriteLine(I);

}

Notice that we have to enumerate all the members of B in order to add it to A, and it’s not intuitive what is being done.
What if we wanted to write B.CopyTo(A) naturally? Can we do it? With Delphi and class helpers, we can!

{$APPTYPE CONSOLE}

{%DelphiDotNetAssemblyCompiler ‘$(SystemRoot)microsoft.netframeworkv1.1.4322System.dll’}

uses
SysUtils, System.Collections;

type
TCopyToArray = class helper for ArrayList
procedure CopyTo(AArrayList: ArrayList); overload;
end;

procedure TCopyToArray.CopyTo(AArrayList: ArrayList);
var
O: &Object;
begin
for O in Self do
AArrayList.Add(O);
end;

var
A, B: ArrayList;
I: Integer;

begin
A := ArrayList.Create(3);
B := ArrayList.Create(5);

for I := 1 to 3 do
A.Add(I);
for I := 5 to 9 do
B.Add(I);

B.CopyTo(A);

for s in B do
WriteLn(s);
end.

Of course, the great Danny Thorpe once said,

The simplest answer is often the best: personal preference.
Why do people prefer one kind of car over another? There are many different kinds of cars, but they all serve basically the same purpose and are built pretty much the same way. Some believe that the car they drive is an expression of their personality or status some believe their car is actually technically superior in manufacture to his neighbor’s; some believe their car is an unreliable pile of junk and modify their daily pattern to accommodate their paranoia. There are many rationalizations for choice, but only one consistent answer: emotion. Personal preference. We prefer what we are comfortable with, or what excites us, or what makes sense to us, individually. And we will rationallize to absurd extremes to justify that emotional choice.

Cognitive psychologists and linguists hold that language not only represents our thoughts, but that the structure of a language can influence the structure of our thoughts, how we think about an issue or visualize an idea. A subtle distinction that can be expressed in a word in one language may require pages in another. If you are using the latter, would you express that nuance regularly, or even at all? No! It’s too much work. The idea doesn’t fit well into your language’s range of expression.

Are programming languages that different from spoken languages? Does a Fortran programmer deconstruct a programming problem differently than a Cobol programmer? Absolutely! Not only are the syntaxes different, but the data handling concepts behind these languages are fundamentally different as well.

Should a Fortran programmer be forced to write code in Cobol? Probably not, particularly if the programmer relates well to Fortran. The cliche’ here would normally be "Use the right tool for the job" but what many people overlook is that the tool, the thing that solves problems, is not the programming language - the critical asset to solving the programming objective is the programmer. The programmer can be inhibited by ill-fitting tools built for a different view of the world, or the programmer can be empowered by comfy tools where things make sense and ideas click into place. No two people think alike, so no one tool can be a best fit for everyone.

For best results, use the right tool for the programmer.

-Danny Thorpe
Delphi Compiler Architect
Borland

Share This | Email this page to a friend