what does the "T" mean?

Replies to This Discussion

Permalink Reply by David Rutten on November 30, 2011 at 7:29am

T is the usual shorthand for Type or Template (actually not sure which). Just as i is the usual shorthand for Iteration in a for loop.

 

A Template (also called Generic Type in .NET) is a class that isn't quite finished at designtime. The easiest way to imagine it would be to simply Find/Replace all instances of T in the class source code with whatever type you want to get the ultimate class. For example, imagine the following case:

 

public class Formatter<T>

{

  private T m_data;

 

  public T Data

  {

    get { return m_data; }

    set { m_data = value; }

  }

 

  public string SmartFormat()

  {

    if (m_data == null) { return "null data"; }

    string frm = m_data.ToString();

    if (frm.Length <= 50) { return frm; }

    return frm.SubString(0, 50);

  }

}

 

The <T> indicates this class is a Generic Class. When you create a new instance of this class, you have to supply an actual Type to be slotted into T:

 

Formatter<Rhino.Geometry.Brep> form = new Formatter<Rhino.Geometry.Brep>();

 

At this point all instances of T will be replaced by Rhino.Geometry.Brep.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Andrea Lu on November 30, 2011 at 8:11am

Thank you,David

 I will try to learn C# to understand it in thesedays,though i cant totally understand you.

 

 

Permalink Reply by Damien Alomar on December 1, 2011 at 4:49pm

In addition to what David said, the concept of Generics is an important one and something that's a big jump from the Rhinoscripting world, as well as the old .Net SDK to RhinoCommon.

 

To start, lets look at what an array, which is the standard means of having a collection of objects in most programming languages.  An array is a type within itself, yet it contains other objects, which have their own type.  Most scripting languages let you put whatever you want in an array, which is fine and dandy. 

 

This causes a problem in strongly typed languages (ie one that requires you to specify your type when you declare your variable), because knowing that I have an array isn't really enough.  You've also got to know the type(s) of the object within your array.  Now you could just always cast your object when you're retrieving it from an array or have some special methods to ensure that you only put objects of a specific type into your array, but that's tedious and a lot of code that needs to be rewritten potentially for each array you have.

 

Enter Generics.  If you boil it down, generics are a way to associate one type (or multiple types) with another type.  The first place this pokes its head is with the array problem.  Rather than having an "untyped" array, you can associate the type of your of your choosing with a List, which forces all of the objects within that List to be of the type you specified.  Now you've got all of your objects in an easy to access manner, which doesn't require special methods to get things in or casting to get the right type out.  Since .Net 2.0 this has become one of the preferred way of programming with collections, so much so that almost every type within System.Collections has a generic counter part in System.Collections.Generic.

 

Now the reason I say that its merely an association of one type to another is that generics don't require there to be a collection involved.  If I'm building a Pattern class, I may need to know what type I'm creating a pattern of, is the pattern numbers, letters, or even shape.  Well if I have a Pattern<T>, now I can know what type of pattern I'm expecting, which I can use to change or adjust how I search for the pattern, or whatever else I may need it for.

Permalink Reply by Andrea Lu on December 2, 2011 at 3:36am

thankyou ,Damien

i have read your reply,and understand something!