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?

Comments

  1. 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).

    The 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)

    ReplyDelete
  2. 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. 

    var
      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.

    ReplyDelete
  3. Lars Fosdal maybe we should give it a second thought, in general not just generics.

    There 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.

    ReplyDelete
  4. 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?

    ReplyDelete
  5. Dorin Duminica 

    Some of the new syntax is perhaps a tad befuddling, and some is very inconsistent.

    Take deprecated in XE3 - See separate post.

    ReplyDelete
  6. Colin Johnsun all I want is your opinion, not really interested if your opinion is wrong or right, I just want it! (:

    ReplyDelete
  7. Another construct that I find a bit dislodged and disconnected, is how you specify attributes.  

    Suddenly 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)];

    ReplyDelete
  8. 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.

    ReplyDelete
  9. Lars Fosdal Putting attributes in the same line as the member makes it super unreadable imo.

    ReplyDelete
  10. Lars Fosdal totally agree, I'd restrict attributes to types only and make the syntax like:
    type 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]);]

    ReplyDelete
  11. On second thought, Stefan Glienke is right, for properties it would probably make more sense to do attributes Attr1; Attr2; ...; end;

    ReplyDelete
  12. Stefan Glienke - I agree, especially if there are multiple attributes - but they currently are too "loose".

    We 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.

    ReplyDelete
  13. Lars Fosdal yeah... maybe replace "has" with "uses" then you can reuse the keyword and also makes more sense? i.e.

    property Kinky: Integer
                   *uses*
                   MyAttr_One(), MyAttr_Two();

    ReplyDelete
  14. uses is already ... used ;)
    properties have attributes, they don't use them, per se.

    ReplyDelete
  15. 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.

    ReplyDelete
  16. Not sure.  I've done too little C# to know.

    ReplyDelete
  17. the syntax is the same as in C# for attributes.

    ReplyDelete
  18. Maybe it was EMBT way of getting Delphi developers who have moved to .net to reconsider Delphi again. Who knows?

    ReplyDelete
  19. Colin Johnsun I'd be very surprised if that would be the case (: but you never know...

    ReplyDelete

Post a Comment