January 5, 2006
A T for my TClasses
I've always liked Delphi's naming convention, but wasn't really sure if there weren't better options in other libraries. At first sight, .NET class library habit of using plain class and types names seems more readable. But I've recently found a very strange situation where the lack of a good convention stands out, for the worse.
Here goes the example. A Form in WinForms has a DialogResult property (corresponding to Delphi's ModalResult property). This is an enumerated value of type DialogResult. Yes, the property name and its type name are identical. You disambiguate the first by prefixing it with self (a common practice in C# that I do not like) and the second by prefixing it with the full namespace name:
self.DialogResult := System.Windows.Forms.DialogResult.OK;
If you fail to spell out the second, the compiler will stop with an error. It is even worse that if inside any method of a form you call MessageBox.Show and check the result (again of type DialogResult) you end up referring to the property, not the the type, unless you specify the full namespace. Needless to say, I find this annoying. This situation is fairly frequent in the FCL library, but the fault is not on the specific property or type names. The fault is on the type naming convention (or the lack of it) in the library. So let's keep our TClasses in Delphi and be happy with them.
7 Comments
T is good, even if it is the initial letter of Trouble :-)
I totally agree with you, Marco. Recently, I read a book about .NET architecture and C# language. I perfectly remember about a paragraph talking about conventions in naming types and identifiers: it says that prefixing classes names with a letter is a bad habit because the meaning of a type, and what kind of type it is (class, enumeration and so on...) should be deduced from the full name itself, without the need to use that "ugly" prefix convention. After reading that sentence, I have turned the page and found the explanation of...IDisposable. So what's that "I"? :-) Joking aside, I often found myself using the same "name" for a property and the data type it belongs to, so the "T" prefix let me remove the ambiguity in a breeze, with no effort, but without abusing of them. I warmly hope to code these "T" for a long time... :-)Comment by Marco Breveglieri [http://www.marco.breveglieri.name] on January 5, 03:18
To Eber
Eber, I think you're right about the fact that C# creators should have copied from Delphi. :-) Maybe they had even thought about that before. However, from Microsoft point of view, I am sure that "no-T convention" is the right option because it makes C# look more similar to Java (so Java developers can migrate to .NET easily) and - on the VB.NET side - it ensures a higher compatibility with ActiveX control names, aiding VB developers to port their existing projects and develop new ones. I think the "T lack" is not a pure matter of code elegancy; in fact, interfaces are "I" prefixed (but they were already expressed with that convention in the "COM era", so it doesn't hurts Visual Studio and COM developers). In my opinion, the "&" prefix doesn't bother you so much once you get used to it. :-)Comment by Marco Breveglieri [http://www.marco.breveglieri.name] on January 5, 17:10
A T for my TClasses
I see where you are coming from Marco but I never have this problem using C# and Visual Studio. I always write it like : DialogResult = DialogResult.OK; -- RobertComment by Robert Kozak [http://TheArtOfProgrammingWith.Net] on January 5, 19:24
A T for my TClasses
Delphi has type equivalence. Therefore, it is possible to declare T prefixed equivalents for any .NET type, put them in a dedicated assembly (that is required at compile time only) and forget about .NET case sensitive oriented naming convention. For details: http://cc.borland.com/Item.aspx?id=23014 http://cc.borland.com/Item.aspx?id=22872 This program (source included) is a not trivial example of use of this technique http://cc.borland.com/Item.aspx?id=23227Comment by Mauro Venturini on January 5, 21:08
A T for my TClasses
"However, from Microsoft point of view, I am sure that "no-T convention" is the right option because it makes C# look more similar to Java (so Java developers can migrate to .NET easily)" that's exactly my thinking, but I was thinking they tryied to make C# more C,C++"ish", but I guess Java"ish" as well, if they would've gone with the "T", it would've been more obvious all the inheritance that C# has from Delphi, but this way, very few people are aware of this fact and people are more comfortable that C# is an "extension" to their current language, I've noticed people are very surprised when I tell them "this or that feature came from Delphi"Comment by Eber Irigoyen [http://ebersys.blogspot.com] on January 5, 22:25
A T for my TClasses
Thanks Marco!!! I'm new to delphi DOT net and I've been battling with dialogresult!!! I eventually got it working when prefixed with the namespace, but I had no idea what was going on. Thanks for the explanation.Comment by Trevor on April 30, 11:58
Post Your Comment
Click here for posting your feedback to this blog.
There are currently 0 pending (unapproved) messages.



A T for my TClasses
Comment by Eber Irigoyen [http://ebersys.blogspot.com] on January 5, 01:17