I've read Nick Hodges 's chapter on generics from his upcoming book.
I've read Nick Hodges 's chapter on generics from his upcoming book.
He likes to refer to generics as parameterized type, which makes a lot of sense if you think about it, never gave it a second thought until now.
As you know, in Delphi(and Pascal in general), we have a convention to name types(except for the primitive ones: byte, boolean, integer, string, etc.) starting with capital T.
Now, for some reason, the above holds true for generics, but I have a strange feeling that it's a bit misleading, a generic isn't a true type until you specialize it, i.e.:
// TIntegerList is a true type
type TIntegerList = class (TList);
or
// variable type "specialized inline"
var LIntegerList: TList;
Maybe, we should come up with a convention for naming generics, let's say capital G -- some might argue that G should be reserved for "global" variables, to which I agree -- or maybe, just drop the T and ta-da!!
Let's drop the T for a second and see how it goes:
type TIntegerList = class (List);
or
var LIntegerList: List);
Note: I've been using generics for some time now -- not to the level some of you used them -- and never had any issue with the T naming convention for generics, however, I thought it would be interesting to see what you guys think and have to say.
What do you think?
How do you name your generic types?
He likes to refer to generics as parameterized type, which makes a lot of sense if you think about it, never gave it a second thought until now.
As you know, in Delphi(and Pascal in general), we have a convention to name types(except for the primitive ones: byte, boolean, integer, string, etc.) starting with capital T.
Now, for some reason, the above holds true for generics, but I have a strange feeling that it's a bit misleading, a generic isn't a true type until you specialize it, i.e.:
// TIntegerList is a true type
type TIntegerList = class (TList
or
// variable type "specialized inline"
var LIntegerList: TList
Maybe, we should come up with a convention for naming generics, let's say capital G -- some might argue that G should be reserved for "global" variables, to which I agree -- or maybe, just drop the T and ta-da!!
Let's drop the T for a second and see how it goes:
type TIntegerList = class (List
or
var LIntegerList: List
Note: I've been using generics for some time now -- not to the level some of you used them -- and never had any issue with the T naming convention for generics, however, I thought it would be interesting to see what you guys think and have to say.
What do you think?
How do you name your generic types?
I name them like (almost) any other type with a leading capital T. Usually I also just use the T for the type parameter (unless there are two or more like for a dictionary).
ReplyDeleteThe only types I don't use the capital letter T are record types that wrap an interface to use them like some simple data type like Event, Lazy, Nullable or Enumerable (more about the last one coming in Spring4d soon)
T or no T - doesn't make much of a difference, but I still mostly use TName for Type in Generics type declarations, mainly because it leaves the Name available for variables.
ReplyDeletevar
Cart: TCart;
I've largely moved away from the old C school type prefix for variable names, except in forms, where I prefix the controls with something that helps me remember the type of the control.
Generally, I also try to move away from short variable names to improve code clarity.
Instead of
sp, cp: TStoragePosition;
I'd use
SearchPosition, CurrentPosition: TStoragePosition;
But - again - not always. What ever makes the code readable.
Lars Fosdal maybe we should give it a second thought, in general not just generics.
ReplyDeleteThere are 3 main reasons for me using Delphi(sorted by importance -- as I see it, you may disagree):
1) clear syntax
2) fast compiler
3) the IDE
but if you think about last few releases we can see a trend:
1) syntax gets weirder and weired, i.e.:
- record helper for
- reference to -- this is debatable, I would have named it "... = anonymous function|procedure ..." -- for all you "shorter code" advocates, I'm sure you would have loved this one, am I right? (:
2) compiler gets slower and slower
3) IDE gets buggier and buggier
Now, I agree with you on the T or no T -- already stated that I've been using it so and haven't had a problem until now -- but if you think about it, if the trend continues for a few more releases, the language is going to get very confusing very quickly.
I probably would just leave the T where it is. It's a well understood convention in Pascal. I mean, doesn't the angle brackets already tell you that it is a generic type?
ReplyDeleteDorin Duminica
ReplyDeleteSome of the new syntax is perhaps a tad befuddling, and some is very inconsistent.
Take deprecated in XE3 - See separate post.
Colin Johnsun all I want is your opinion, not really interested if your opinion is wrong or right, I just want it! (:
ReplyDeleteAnother construct that I find a bit dislodged and disconnected, is how you specify attributes.
ReplyDeleteSuddenly I have sequence oriented declarations, and if someone adds a new prop in the declaration, and accidentally place it among the existing attributes, it folds like a house of cards.
[EmailFormat]
property That:String;
[Mandatory]
[DefaultMinMax(50, 1, 100)]
property This:Integer;
[EmailFormat]
property That:String;
[Mandatory]
property NotImportant:String;
[DefaultMinMax(-1, 1, 100)]
property This:Integer;
It would have been more logical to have it either after the leading keyword or before the semicolon and these variants would have been a lot more robust.
property [EmailFormat] That:String;
property NotImportant:String;
property [Mandatory] [DefaultMinMax(-1, 1, 100)]This:Integer;
property That:String [EmailFormat];
property NotImportant:String;
property This:Integer [Mandatory] [DefaultMinMax(-1, 1, 100)];
Dorin Duminica I thought I was stating my opinion. I neither stated that my opinion was right or wrong. I just said that I would use the T prefix and that it is my preference. But, if I wasn't making myself clear, my opinion is that it is better to prefix generic types with a T as it is the Pascal convention to prefix types with a T. If there is a need to distinguish a generic type vs non-generic type, then I believe the angle brackets would make that perfectly clear. That is my opinion.
ReplyDeleteLars Fosdal Putting attributes in the same line as the member makes it super unreadable imo.
ReplyDeleteLars Fosdal totally agree, I'd restrict attributes to types only and make the syntax like:
ReplyDeletetype TMyClass = class
attributes
// attributes section
MyAttribute([args]);
MyOtherAttribute([args]);
//...
protected
private
public
published
end;
same as above for record since now days a record is more like a class...
for properties, I'd go with:
property X: type; [default;] [attributes MyAttribute([args]), MyOtherAttribute([args]);]
On second thought, Stefan Glienke is right, for properties it would probably make more sense to do attributes Attr1; Attr2; ...; end;
ReplyDeleteStefan Glienke - I agree, especially if there are multiple attributes - but they currently are too "loose".
ReplyDeleteWe could always do a line break and an extra keyword :)
property That:String
has [EmailFormat];
property NotImportant:String;
property This:Integer
has [Mandatory]
[DefaultMinMax(-1, 1, 100)];
Dorin Duminica - That doesn't work for me. Attributes need to be per property.
Lars Fosdal yeah... maybe replace "has" with "uses" then you can reuse the keyword and also makes more sense? i.e.
ReplyDeleteproperty Kinky: Integer
*uses*
MyAttr_One(), MyAttr_Two();
uses is already ... used ;)
ReplyDeleteproperties have attributes, they don't use them, per se.
Isn't the syntax for attributes just borrowed from c#? I guess if you are familiar with c# then attributes in Delphi would be a no-brainer for you.
ReplyDeleteNot sure. I've done too little C# to know.
ReplyDeletethe syntax is the same as in C# for attributes.
ReplyDeleteMaybe it was EMBT way of getting Delphi developers who have moved to .net to reconsider Delphi again. Who knows?
ReplyDeleteColin Johnsun I'd be very surprised if that would be the case (: but you never know...
ReplyDelete