What you need to know about cloud backup

Declare methods once. We really should be able to declare methods inside a class, as in the Java model. All this interface/implementation division stuff is alarmingly COBOL-like, and feels like a hangover from 1975 designed to make writing compilers slightly easier.

Besides, some of us are not as young as we once were; by the time we have scrolled down from the class declaration to the spot in the file where we had planned to implement the method, we have not only forgotten its name and its parameters, we have also forgotten what it was going to do and what we came here for and who is the prime minister again? Is it still that nice Mr Blair?

And declare variables anywhere. Again, a lurch away from the 'everything has its place' approach of 1960s languages. We should be able to write

for var I:integer := 0 to 10 do
...

and have that work as expected, with I declared in the scope of the for loop like recent C++, and not using some insane JavaScript-stylee rule thank you very much.

By the way, did you notice that I smuggled in a second demand there: that we should be able to initialise stack variables in situ.

What about garbage collection, Verity? I am coming to that. Sheesh, give me a chance.

Case sensitivity in identifiers. As things stand, Object Pascal ignores case in identifiers. So if you want to register some home-brewed components, you can declare your registering procedure

procedure register;

or

procedure REGISTER;

according to taste.

Haha, got you! Neither will work, because Object Pascal ignores case in identifiers except the Register procedure which must be declared

procedure Register;

Surely CodeGear can to do better than this. Case insensitivity is a pain in the elbow, again associated with Jurassic uppercase-only printers that made variables called 'PenIsDown' look rude. If one declares MY_CONST in one scope and my_const in another, you just don't expect one to hide the other.

And for another thing, we are always having to interface with languages that do take case seriously, starting with all the DLLs in the Windows API. I think it's time to throw in the towel on this one, siblings.

I recognise this is quite a big change, so when it hits an unidentified symbol, the compiler should search its hash table, suggest the intended spelling, and offer to correct the code and continue compiling. That will help contain the pain.

While we are on identifier confusion. The with keyword. The most hideous, dangerous, blow-your-own-feet-off feature in the language. What's that you say, Sweep? You use with to give the compiler a hint as to which variables to put in index registers? Ooh, you lying little hand-puppet, you.

OK, if it proves to be impossible to kill with, at the very least limit it to one record at a time. And change the spelling of the keyword to caution_stupid_programmer_with. And switch to the VB convention of requiring the programmer to prefix the fieldname with a period:

caution_stupid_programmer_with MyRecord do
begin
.FMyField := 'Look, I''m Stupid!';

But what am I doing? Borrow a Visual Basic feature in order to improve Delphi? Better to go on a weekend winter waterboarding holiday with ex-president George W. Did we fight and win the great VBX war of 1998 for this? Sack the damn thing and be done.

A tweak to the system of overriding methods. Let's steal the new method modifier from C# to do method hiding. Can't be bothered to explain it here - it adds a smidgen more expressivity to the language - just read it up in MSDN.

Well, why not? The C++/Java systems of overriding are stuff-ups, and Delphi is already better. But is it not a pleasure and duty to add another few ounces of Hejlsberg goodness? Who cares if we half-inched them? Great artists...

Do more with const. Pretty well the only practical thing we do with const in Object Pascal is apply it to parameter strings. This is ok as a piece of optimisation (have you seen the amount of guff that gets generated to cope with strings passed by value? Or what about a variant? Get thee to a disassembler...) but is limited as a tool for expressivity. I want to be able to write: 'this method promises not to poke its fingers into the state of its owning object'. No, really, it's enriches the design; it's one of the underrated virtues of C++.

So what about garbage coll... Yes, yes. In a minute.

On reflection... Delphi really should have wider support for reflection, and it should be more sincere - ie less fiddly to use, not buried away in an obscure unit. Waves hands vaguely. Make it so.

Closures. We really must get closures. Oh, wait - we already have them. (Excuse me, still on Delphi 7, haven't yet switched to D2009 in anger.) Anyway, take that, Java! Ha!

You know, try...finally is not really a great way to protect resources. It is just too ad hoc. The problem is that sooner or later this happens:

A := nil; B := nil;
try
A := TSomething.Create;
B := TOther.Create;
// Lines of code using A and B
...
finally
FreeAndNil(A);
// But forgot B - easily done so far away from the Create
end;

Others have had a go at this problem. The C# IDisposable/using thing, explained here, feels like a bit of a kludge. I prefer C++'s 'Resource Acquisition Is Initialisation' idiom, which relies on the destructors of stack-allocated objects getting called automatically when they go out of scope. This idea can be extended to make so-called smart pointers, which use reference counters to produce allocated objects that not only do the right thing when under exception-stress (ie get freed at the right time without having to write special code).

Delphi doesn't have stack objects, but it does have objects with automatic reference counters - interfaces. These can be used to make C++-like smart pointers - here it is being done. Now, if only there were a little bit of syntactic sugar in the compiler, so that this scheme was a little more straightforward to implement and use, I reckon we could have a Delphi idiom that would do the trick nicely.

Customer Success Testimonial: Recovery is Everything