FWIW, I've updated the blog description in the header of my blog, to better reflect what I'm actually writing about ;). The new description reads: "Confessions of a Delphi hacker - hacks, programming tips and Delphi stuff." Oh, btw, I've just returned the corrected proofs of my upcoming Delphi Magazine article to the editor - it looks good! Make sure you have that subscription updated... ;).
In a small series of blog articles I'm planning to talk about some of the different types of casts and conversions that Delphi supports, and mention any differences in casting logic and implementation between Win32 and .NET.
In general, using casts in your code indicates an impendence mismatch between your design and the problem domain. Sometimes they cannot be easily avoided, other times it might be better to refactor your design and code to remove or reduce the number of casts. Until true generic classes become available (as they probably will - at least for .NET 2.0), it is close to impossible to have no casts anywhere in the code. They can (and should) be encapsulated to a few core locations, however - typically in type-specific collection classes.
For the purposes of this discussion, I've identified 9 separate categories of casts, in terms of the types of the entities we are casting to and from.
Types of casts:
1. Object-to-object upcast4. Interface-to-interface cast
5. Interface-to-object cast
6. Valuetype-to-valuetype cast
7. Valuetype-to-object cast
8. Object-to-valuetype cast
9. Casts to and from compiler-managed types
The upcoming blog posts will each discuss one or two of these casting categories.
N. Ismail commented on my last post about the with-statement:
"I recommend the with statement be extended to allow it to also be written as such:
with a: Form1 do
begin
a.foo := 123;
a.bar := 'xyz';
a.Caption := 'Test';
Caption := 'Foo Bar'; //The forms caption
end;"
IMO, the with statement should not be extended.
Here are my reasons:
#1. This will help nothing for existing code. Existing code uses with the old way, so the compiler would have to support that syntax for foreseeable future.
#2. Enhancing the with-statement will encourage increased use of it, which is a bad thing, IMO. My suggested warning should encourage decreased use.
#3. What you want can easiliy be obtained today and work in all versions of Delphi. Just define the identifier as a local var and get rid of the with, like this:
var
a: TForm1;
begin
a := Form1;
a.foo := 123;
a.bar := 'xyz';
a.Caption := 'Test';
Caption := 'Foo Bar'; //The forms caption
end;
"Obviously one could have declared a variable named 'a' of same type as Form1,"Exactly ;)
"but I think the above syntax is cleaner"
As have been mentioned by several people in several places (newsgroups, blogs, QC etc.) Delphi's with-statements can be harmful to the readability, maintainability and robustness of your code. Not to mention it makes debugging harder ;).
Much like the problem with potential duplicate identifiers from used unit scopes, the with-statement problem could be mitigated by enhancing the compiler to produce Warnings for ambiguous with-statements.
Consider the following code:
Unit Foo;
type
TGadget = class
bar: integer;
end;
//----
Unit Bar;
var
a: TGadget;
foo: integer
begin
with a do
foo := 123;
end;
This is version 1. Code compiles without warnings and works correctly. Now Mr. Component on the other side of the globe makes an update to the TGadget class:
Unit Foo;
type
TGadget = class
foo: integer; // New feature!
bar: integer;
end;
Then John Doe recompiles his code with this new version:
Unit Bar;
var
a: TGadget;
foo: integer
begin
with a do
foo := 123;
end;
Currently, with D7, there is no warning. Code compiles, but it fails mysteriously at run-time. In a future version of the compiler he could get warning such as: Warning: Potential name conflict: foo declared in unit Bar and Foo.TGadget. In this case, to get rid of the warning, the programmer could change the code to
Bar.foo := 123; or (even better) he could just get rid of the with-statement.
IMO, if we could have this kind of warning for with-statements, it would be the first steps towards patching one of the very few sorespots of the otherwise elegant Object Pascal language. (and before you ask, yes, this has been QC'ed: #8770).
(The headline plays with Edsger Dijkstra's famous article "Go To Statement Considered Harmful") Because the way unit references in the uses clause work in Delphi, you could occasionally get weird and even buggy effects because of changes made in one of the units you use. Note that in general, Delphi handles modularity and code imports much cleaner than most other programming languages. Still there is room for some improvement.
My suggestion is that the Delphi compiler be improved to emit a new Warning for potential name conflicts when the same identifier is imported from two or more units. The goal is to catch unintended changes in semantics after changes have been made to used units.
If I have two units, A & B, both of which export the identifier foo and then in another unit I write:
uses A, B;
// ...
begin
foo;
end.
Here the reference to foo is without a unit prefix. Currently I would get no warning. My suggestion is to generate a warning, something like this:
"Warning: Potential name conflict: foo declared in unit A and unit B."
To resolve the warning, the programmer would prefix foo with the intended unit name:
begin
A.foo;
end.
This would then generate no warning. Technically, the reference to 'foo' isn't really ambiguous. That's why you shouldn't get a compile error. But like most warnings, this one should be there to catch potential human error or confusion. You have two possible sceniarios:
#2 is the most dangerous and where the warning would be most useful.
John Kaster of Borland just posted a new BDN article about the upcoming BorCon 2004 and the tracks devoted to the next version of Delphi, code-named DiamondBack! Borland hotshots like Danny Thorpe, Allen Bauer, John Kaster, Jim Tierney, Corbin Dunn & al will reveal the new cool features. Check it out: http://bdn.borland.com/article/0,1410,32499,00.html
Due to the length and style, the following hack has been turned into a The Delphi Magazine article. IMO, this is simply the best Delphi magazine for professional developers and I highly recommend a subscription. Don't forget to get the Collection CD to read all my old articles :-) (in addition lots of other great articles too, of course).
Read the magazine article (update: in the October issue) to get the complete hack, explanations, history, the clean alternative, sample code and .NET comparison. As a teaser, here is the actual hack code:
function GetImplementingObject(const I: IInterface): TObject;
const
AddByte = $04244483;
AddLong = $04244481;
type
PAdjustSelfThunk = ^TAdjustSelfThunk;
TAdjustSelfThunk = packed record
case AddInstruction: longint of
AddByte : (AdjustmentByte: shortint);
AddLong : (AdjustmentLong: longint);
end;
PInterfaceMT = ^TInterfaceMT;
TInterfaceMT = packed record
QueryInterfaceThunk: PAdjustSelfThunk;
end;
TInterfaceRef = ^PInterfaceMT;
var
QueryInterfaceThunk: PAdjustSelfThunk;
begin
Result := Pointer(I);
if Assigned(Result) then
try
QueryInterfaceThunk := TInterfaceRef(I)^.QueryInterfaceThunk;
case QueryInterfaceThunk.AddInstruction of
AddByte: Inc(PAnsiChar(Result), QueryInterfaceThunk.AdjustmentByte);
AddLong: Inc(PAnsiChar(Result), QueryInterfaceThunk.AdjustmentLong);
else
Result := nil;
end;
except
Result := nil;
end;
end;
