Methods for implementing Tuple in. NET 2.0

When I introduced Visual Basic 9.0, I mentioned the concept of Tuple many times. At that time, it appeared as an anonymous instance. Now let's discuss this concept separately. Tuple is often translated as "group meta". In most languages that support TupleThe number of members is determined, and each member type is also determined.. It is often used to indicate multiple return values of a function or query results. Tuple should be strongly typed, that is, the types of all Members are determined during compilation. For example, in the hypothetical syntax

Dim t = New Tuple (Of String, Integer, Double)

T has three members, and the number cannot be changed. The types of the three members are String, Integer, and Double. As you can see, Tuple can be seen as a struct that does not need to be declared in advance, and can be flexibly created based on the Use Cases. Therefore, the anonymous type of VB9 and C #3 is of course a good implementation scheme of Tuple. But this is all about N years later. Can we implement Tuple in. NET 2.0? The most critical difficulty is that we need to create a Tuple structure where we want to use it, instead of declaring it in advance, so we must have a flexible mechanism to complete it.

Method 1: TypeList

I thought of this method on the bus one day, and later I saw similarities with Loki's TypeList. Of course,. NET does not have the ability to customize and record types, so it cannot implement TypeList. However, when we move the idea of static type operations to the runtime, we can do the Typed Variable List-that is, Tuple.

Public abstract class TypeNode {internal TypeNode {}}

Public sealed class Tail: TypeNode {}

Public sealed class Tuple <T, TNode>: TypeNode where TNode: TypeNode, new ()
{
Public T Field = default (T );
Public TNode Next = new TNode ();
}

I made full use of the constraints of. NET generics to achieve my design. TypeNode is designed as abstract, so TNode, a new ()-constrained generic parameter, cannot be set to the type of TypeNode. Its internal constructor limits the user to inherit from it. This method limits the value range of TNode to two types: Tail and Tuple. This is a clever method in my opinion.

The principle of this type is very simple, that is, the generic type is used to automatically generate a linked list with the same structure when the TypeList instance is created. For example, we want to create a Tuple of String, Integer, and Double, which is written as follows:

Tuple <string, Tuple <int, Tuple <double, Tail >>> t;

As you can see, the first type of Tuple is the type of a node, the second is either another Tuple or Tail (indicating the final list ). After this object is created, a linked list with different node types is automatically generated.

T = new Tuple <string, Tuple <int, Tuple <double, Tail >>> ();
T. Field = "a string ";
T. Next. Field = 123;
T. Next. Next. Field = 13.56;

Tail does not have the Next field. Therefore, Tail means that Tuple is terminated. This can be checked by the compiler, so there is no danger of crossing the border. In addition, this Tuple can be infinitely long. However, this method is also flawed. The first syntax is inconvenient. If you want to use 7th fields, write them as myTuple. next. next. next. next. next. next. field. If you do not pay attention to it, you will write an error. Both VB and C # do not have sufficient abstract capabilities to simplify this operation. The second defect is the overhead of a series of new operations when creating a Tuple, because the new operation is implemented through reflection. Due to the lack of language features, this method cannot be perfect, but this idea may be used in other occasions.

Method 2: Heavy Load prototype

Imitating the idea of generic delegation, we can use a series of fully generic structures with the same name to simulate the instant creation of Tuple:

Struct Tuple <T0>
{
Public T0 Field0;
}

Struct Tuple <T0, T1>
{
Public T0 Field0;
Public T1 Field1;
}

Struct Tuple <T0, T1, T2>
{
Public T0 Field0;
Public T1 Field1;
Public T2 Field2;
}
......
Struct Tuple <T0, T1, T2, T3, T4, T5, T6, T7, T8, T9> {...}

In this way, a set of Tuple structures are created. Because the names are the same, there are no 10 types in use, but "What are there ":

Tuple <string, int, double> t1;
Tuple <string, string> t2;
Tuple <int, float> t3;
......

This is the same as the hypothetical syntax at the beginning! And there is no additional overhead, Which is perfect. However, it has a limited number of elements and can only have a few defined at the beginning. Fortunately, it generally does not need too many elements, and 10 elements are enough. However, the Tuple generated in this way is a little rigid, and there seems to be nothing intelligent.

I will use the second Tuple scheme in my VBF. I think it is more practical after consideration. The only change is to add a constructor for each Tuple structure to initialize all members.