I've just read an extremely interesting (and long) article about the future of Delphi. The catalyst for the article was Nick Hodges post on the future of Delphi. Some interesting things on the wish list for the new Delphi.
Compiler Speed
For most of my professional life I have used Delphi, and Turbo Pascal before that. I take the compiler speed for granted, and compile my code often, just because I can. I think I'd notice if the Delphi compiler was to all of a sudden take a lot longer to produce the goods, and I would not be happy!
Interface/Implementation
I'm all for typing less code, but not at the expense of clarity. Having to declare the class in the interface section, and the implement it in the implementation section may seem like a waste of time, but it makes Pascal so much more readable than say C#. Even if we didn't have shortcuts such as ctrl+c (complete class) or ctrl+shift+up and ctrl+shift+dn (toggle between interface and implementation), I'd still want a separate interface and implementation section.
Declare Inline Variables
I've started using these in Delphi Prism, and they rock. Now this is one place where you write less code (albeit a little less), but clarity improves.
for var i : Integer := 0 to 20 do
Case Sensitivity
No. No. No. Why? Why? Why? I don't get it. If I have two variables test and Test, in the same scope, then I've just introduced an ambiguity. Which one do I use? Which one did I mean to use last year?
No. No. No.
With Statement
I don't like it, I don't use it, and I think people who write code such as :
with MyObject, HisObject, TheirObject do
Should be shot! (yes I have seen code like that)
Smart Pointers and Garbage Collection
The author is basically for some form of smart pointers and against garbage collection. I'm on the fence here. As long as anything is optional in this area, then go for it. I'll make my decision after I've seen it in action.
There were a few other points, but the ones above were the interesting ones. I just hope the rewrite of the Delphi compiler is the right thing to do. Look what happened to Netscape when they decided to rewrite their flagship product!
Posts
9 comments:
I agree with everything on here. Apart from "with". When storing to a dataset, I'd be lost without "with dataset do..." followed by a million fieldbyname's.
Thnx
Stuart
Declare Inline Variables:
Teamwork isn't really compatible with that, IMHO.
1) Some procs do use many vars: it helps understand the scope of the proc when you can review all var declarations at once.
2) I barely use "i" as a var name (avoiding it even in very simple procs). I think its a bad habit.
I prefer to NAME the vars like this:
"CustomerListLoop"...
Hey, it's Delphi! We have code completion, no limitation in naming... and we're all working on pretty wide screens ;)
Moreover, my code (i.e. the purpose of the proc) should be easily readable/understandable for my colleagues :)
I agreed about "With" statement: is the worst language feature i know.. in debugging time is impossible to watch any value.. is a real hell debugging "with" statement..
I saw dozens of lines of code entiraly sorrounded by with statements: horrible!
Bye
Corrado
> I'm all for typing less code, but not at the expense of clarity.
I agree, we do not want keypress optimisation if clarity will suffer.
Clarity in code,
power in performance,
that is why Delphi delivers.
CodeGear, keep it that way in the future too, thanks!
"With" can be dispensed with if we get the ability to declare local variables in-line and have them not increase reference counts.
Instead of
With biglongobjectname do begin
Objectfield := stuff;
ObjectMethod(param);
end;
we could write
A := biglongobjectname;
A.ObjectField := Stuff;
A.ObjectMethod(Param);
and then have A go out of scope and no longer be considered a reference for Biglongobjectname.
The with statement is an excellent way to make the code more readable.
Therefore, I agree that binding a with statement on 3 different objects make the code a mess...
And yes with statement "is a real hell debugging". But all this because Delphi cannot resolve variables (as for window [Evaluate/Modify] cannot give you a variable's value while window [Local variables] can...)
If Delphi could evaluate variables properly (even inside a with statement), wouldn't be nice?
Hey, the "A.ObjectField" sample is maybe not far away from a good solution (A:=... is not good enough imo):
WITH ... the "SQL way":
just similar to column labeling in SQL:
With biglongobjectname as A, ... as B do begin
A.ObjectField := Stuff;
B.ObjectMethod(Param);
End;
It wouldnot have the drawback of an assignment, as long as the "A." are for readability only and the compiler do replace them with the correct object address....
WITH ... the "SQL way":
just similar to column labeling in SQL:
With biglongobjectname as A, ... as B do begin
A.ObjectField := Stuff;
B.ObjectMethod(Param);
End;
This could be an excellent solution - it would extend the existing syntax in a compatible way (since you could leave out the "as..." part and have it not require the alias), and yet give the IDE what it needs to resolve the names, and the programmer what he needs to resolve ambiguity.
I like it. If it was in there, I'd use it instead. (I actually do use the temporary variable method. I HATE regular WITH statements.)
I've stopped using the with statement as a lot of the refactorings don't work within a with.
Post a Comment